I agree with many of these comments (were they observed?) but I also agree with the part about “ship it” :-)
Jari On 01 Nov 2014, at 06:10, Martin Thomson <[email protected]> wrote: > 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 > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
