(Please keep the To/Cc; the responsible ADs/shepherds probably need to see these emails. Add ietf@ if you feel you want the larger audience; I figured saag was a large enough peanut gallery :)
On 10 July 2014 19:41, Viktor Dukhovni <[email protected]> wrote: > On Thu, Jul 10, 2014 at 05:16:15PM -0700, Martin Thomson wrote: > >> Major issues: >> >> This misses one of the key principles behind opportunistic security: > > Strongly disagree. Opportunistic security does not always downgrade > to unauthenticated or unencrypted communication. For example, with > opportunistic use of DANE TLS, authentication is enforced for peers > with usable TLSA records, while communication with other peers is > unauthenticated or perhaps even unencrypted. > > So in fact, this draft specifically, and deliberately leaves the > door open for MiTM-resistant authentication of peers for which some > suitable mechanism (DANE, TOFU, ...) makes authentication possible. Maybe I chose my words poorly, but I stand by the fact that this is an important consideration in some designs. More important than this document implies. >> Insistence on failure, as opposed to downgrade or some lesser level >> of security - a characteristic of non-opportunistic security - elicits >> responses from users to work around the problem (accept the bad >> certificate, suppress certificate checking, etc...). > > For MTA-to-MTA SMTP there is no user to click OK. Not all applications > are web browsers. > >> The willingness >> of an opportunistic security implementation to accept unvalidated >> credentials means that it still benefits from resilience against >> passive attack. This is only really noted through an example of a >> "design blunder". > > Opportunistic security is NOT a synonym for unauthenticated > encryption. I didn't suggest that it was, but it's an important feature of the potential design space. The document doesn't really describe any other features that are this prominent. >> The document skirts around it's key goal: defining OS. Section 2 >> needs to start with a definition. The paragraph that follows the list >> in S2 is a reasonable attempt at that and could be tweaked fairly >> perform that function. > > The definition is a summary of the design principles. We're defining > an umbrella term for a family of protocols sharing a design > philosophy. It is helpful to set out the design principles first, and > then state that OS protocols are those that adhere the design principles, > and amplify the key points. I stand by my comment, I think that with a title and subject matter as is, you need to at least attempt to define the subject before attempting to describe secondary things like design principles. >> The Security Considerations is a response to an unstated argument, but >> I think that the document needs to be clearer about what that argument >> is, i.e.: >> >> The willingness of an OS implementation to downgrade can be >> trivially exploited by an active attacker to strip an opportunistic >> mechanisms. > > The Security Considerations section says that some protection is > strictly better than no protection. Thus it is often OK to accept > some protection, even if some risks are left unmitigated. Yes, but as I said, that statement is an answer to a question that is only implied. I think that the document would be better if it owned up to the potential here. >> Section 3 is unnecessary in its entirety: > > No terminology section required? It is a subset of the Terminology > from Steve Kent's draft. If it is felt that all the requisite terms > are adequately defined in-line, I am not opposed to its removal, for > this draft less bloat is better. It should be a succint definition. > >> 1. 2119 language isn't really appropriate for this document. Many >> of the statements that rely on this would be much better without that >> language. Some of the uses are actually completely inappropriate: >> "When possible, opportunistic security SHOULD provide stronger >> security on a peer-by-peer basis." > > I can downcase the "SHOULD", what is the objection to 2119? That's not my point. The point is that you aren't making normative statements in this document, and nor should you. 2119 language isn't needed. For this specific sentence, you could use lowercase "should" and still basically have an unsupportable statement. stronger than what? is this a prediction? I'm not sure what the right language is here, but this reads much like the argument from the security considerations, which is - to my mind - far more precise. >> 2. I think that the description of "unauthenticated encryption" and >> "TOFU" belong in the text proper. TOFU is covered well enough by the >> text in S1; unauthenticated encryption needs to be covered in the >> description as a first class section, rather than piecemeal (see >> above). MitM and PFS are defined in RFC4949. > > Anyone care to suggest new language? Is there agreement that the > proposed changes are needed? I'm thinking that Section 3 could be deleted and the paragraph on unauthenticated encryption beefed up a little to note its key characteristics and significance (deployability, failure in the face of active attack, that it isn't the only or even necessary piece of opportunistic encryption, etc...). _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
