I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:draft-dukhovni-opportunistic-security-05
Reviewer: Martin Thomson
Review Date: 2014-10-31
IETF LC End Date: 2014-11-18
IESG Telechat date: (if known)

Summary: Ship it; it's more important to have this stake in the ground
than it is to have it right.

Major issues:

This is the first attempt at definition, which appears at the bottom of page 3:

   "Opportunistic Security" (OS) is defined as the use of cleartext as
   the baseline communication security policy, with encryption and
   authentication negotiated and applied to the communication when
   available.

So I can't start from an unauthenticated, encrypted baseline?  And I
can't opportunistically add other features (like length hiding)?  How
about:

"Opportunistic Security" (OS) is defined as a security policy that
adds security features - such as encryption or authentication - based
on availability, using negotiation to enable commonly supported
features.

(the next paragraph establishes that cleartext is the baseline anyway)


I still find the paragraph that starts "An OS protocol first
determines the capabilities of the peer with [...]" goes nowhere.
There's no "then" or "second".  It just wanders off.  This is a
crucial part of the definition.  (This also appears too far down in
the document, I'm inclined to suggest that this belongs in the newly
empty Section 1).

OLD:
   An OS protocol first determines the capabilities of the peer with
   which it is attempting to communicate.  Peer capabilities may be
   discovered by out-of-band or in-band means.  (Out-of-band mechanisms
   include the use of DANE records or cached keys or credentials
   acquired via TOFU.  In-band determination implies negotiation between
   peers.)  The capability determination phase may indicate that the
   peer supports authenticated, encrypted communication;
   unauthenticated, encrypted communication; or only cleartext
   communication.
NEW:
   An OS protocol enables security features based on the capabilities that
   can be learned about a communications peer.  This might use out of
   band information, or an in-band negotiation.  As capabilities are discovered,
   they are enabled.  Failure to enable any given feature is not considered
   cause to terminate communications, since each feature is enabled
   independently.

(then you can get into f'rexamples, like the whole auth+enc -
unauth+enc - clear continuum; the STARTTLS quagmire, a DANE example =
to cover opportunistic authentication.)


Minor issues: I'm not excited about writing this, because Victor has
made a genuine effort to engage, and I understand the pressures that
are being applied from multiple directions, but here goes....

My original review noted a couple of structural issues:
 - the document had too many words
 - the definition of OS in S3 was obfuscated

Though some aspects of the draft are greatly improved, and arguably a
new definition is provided (see above), I suggest that these have not
been addressed.  I contributed text and specific editorial
suggestions[1] that would have drastically reduced the amount of text,
but those were apparently only sparingly sampled.

This is only a personal reaction, but the emphasis on DANE is perhaps
a little strong.  I suggested less of that last time (i.e., none); but
there is now more.

[1] https://github.com/martinthomson/saag/commit/63bf358d1101b06460350a6fc5068fdedb3ff6d3
[2] https://tools.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-05.txt