Subject: [secdir] Secdir review of draft-dukhovni-opportunistic-security-01

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 18 Jul 2014 19:33:22 +0900

Hello,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines the term "opportunistic security" and describes its
design philosophy.
The document begins with describing the difficulties to realize perfect
security and talks about the benefit of having opportunistic security.
The term "opportunistic security" is roughly defined at the end of section
1, and section 2 describes the design principles that realize the
opportunistic security.
Finally, the 2nd last paragraph of the section 2 clearly defines the term
"opportunistic security"

It is an interesting document, and I think it is ready.
Considering the intensive discussions in these months(on the saag mailing
list) and the nature of the document (informational), I see no reason to
block the document moving forward.

Below are minor comments.

1.
In addition to defining the term "opportunistic security", this document
also describes the design philosophy of opportunistic security (in section
2).
The abstract could be changed so that it can say this document also talks
about the design philosophy.

2.
It is really just a comment.
When I was reading this document for the first time, I was feeling a bit
uneasy; I was expecting to see the clear definition of the term first, then
to see the design philosophy, but this document describes the design
philosophy of the opportunistic security before having clear definition of
the term(2nd last paragraph of section 2, starting with "In summary").
Having said that, the current structure is also fine, since this document is
short and concise.
Moreover, readers can have clear picture of the opportunistic security in
mind by the time they reach the sentences defining the term.

3.
The security consideration is fairly short, but I think it is ok.
All it says is that opportunistic security is not the maximal security, but
it is much secure than no security. That explanation is fine for me.

Kind regards,

Take

---

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Jul 2014 15:08:39 +0000

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

**** Technical: ****
The two numbered bullets in page 5 (section 2.2) and the first and third bullets in page 6 (Section 2.2) should use RFC2119 language.

**** Nits: ****

Section 1:

> his extension allows a client to search multiple mailboxes
>    with one command, limiting round trips delay

Maybe something like "transaction delay" or something along those lines would be better?

Section 1:
> There is
>    now implementation experience, giving confidence in the protocol, so
>    this document puts the extension on the Standards Track, with some
>    minor updates that were informed by the implementation experience.

You may want to replace "informed" with "motivated".

Thank you,
Tina

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Jul 2014 11:22:23 -0400

Hi, Tina, and thanks for the review.

> The two numbered bullets in page 5 (section 2.2) and the first and
> third bullets in page 6 (Section 2.2) should use RFC2119 language.

I very much disagree; I think it's quite fine as it is, and says
exactly what it needs to.  Is the language unclear?

> those lines would be better?

No, the Introduction section is clear that we want to talk about round
trips.  What you're quoting is from the Abstract.  Lots of App-layer
stuff talks about round trips.  But, yes, "round trips delay" is
awkward.  I think this might work better:

OLD
   This extension allows a client to search multiple mailboxes
   with one command, limiting round trips delay, and not requiring
   disruption of the currently selected mailbox.
NEW
   This extension allows a client to search multiple mailboxes
   with one command, limiting the delays caused by many round
   trips, and not requiring disruption of the currently selected
   mailbox.
END

> You may want to replace "informed" with "motivated".

I very much don't.  "Informed" is actually the right word.  This odd
use of "motivate" has become popular in the tech world in recent
years, but it's not correct English usage, and I've always found it
icky.[1]

Barry

[1] "Icky" is, of course, perfectly correct English....