Re: [Gen-art] Gen-ART of draft-dukhovni-opportunistic-security-05

[Jari Arkko <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art