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