The phrase I would use here is something like 'graceful escalation in the security of communication capability, from cleartext to best, and graceful degradation to cleartext as a minimum where necessary'. Only reworded to be less wanky, of course. As Viktor says, in security minds, there does not appear to be a concept of graceful degradation - either it's considered secure to all possible attacks, or it's (just) been broken and it's not - hence the whole never-ever-use-MD5-ever-in-any-context kerfluffle of old. Expanding the examples to cover http/https will give a better idea of the scope, I think. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf <ietf-bounces@xxxxxxxx> on behalf of Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> Sent: Saturday, 16 August 2014 2:48 PM To: ietf@xxxxxxxx; saag@xxxxxxxx Subject: Re: [saag]: Review of: Opportunistic Security -03 preview for comment On Fri, Aug 15, 2014 at 09:03:09PM -0700, John Wroclawski wrote: > From my point of view, these two wordings are indistinguishable. > Setting a least common denominator and doing better whenever possible > *is* using less-stringent protection when stronger protection is > not available. I understand there?s nuance, relating to per-peer > (which I think everyone agrees with), to the multiple dimensions > of protection, and to whether ?none? is a variant of ?least? or > not. But IMO, fundamentally these two sentences say the same thing. > If the intent is that they don?t, *very* different words may be > needed. Except that it is different. There is no need to make a big "your security may be degraded" fuss when doing better than expected. However, when failing to achieve a security goal, and settling for less, applications have tended to put up all sorts of warnings, fussy dialogues, ... And are often unwilling to do less that the maximum, and simply fail. The change of perspective is crucial to making progress. Cleartext is the baseline, not comprehensive protection. You don't fall back from comprehensive protection, when it is does not work out, ... You do better than the baseline when that is possible, and just works, without disrupting communication in the absence of an attack. This is a design guide (manifesto), not not a protocol specification, and setting things in the right perspective matters. It is important to understand that peer capabilities you can assume to be there are only those that are required and available to all peers, anything else is something that requires a specific capability advertisement. It makes little sense to talk about fallback from authenticated encryption, because authentication is mostly only useful when it is enforced. It makes more sense to talk about enforcing authentication when the peer publishes the appropriate key material (DANE, TACK, ...). The mandated model of security, where everybody has to implement it or they don't play the game, makes sense in top-down environments like the military or enterprises. It is not a good model for the Internet. We've tried it for a few decades now, it has not worked well. It is time for a more flexible, pragmatic approach. I expect opportunistic security to provide more security to more peers than the top-down models we've grown accustomed to. The language matters, it sets the correct mental model for moving forward. We need to prioritize the user's needs (move the bits) first, and layer as much security on top of that as we can, but no more. Yes, you can describe a fun-house mirror view of this, in which we're falling back from comprehensive security, But that is not a good way to think about it. Especially when you conclude that authentication is not opportunistic or cleartext is outside the artificial boundary drawn around opportunistic security, making just unauthenticated crypt be opportunistic security, and everything else is out. The result of that view would be everyone implementing unauthenticated crypto, and calling it a day. That would be a shame, because in the long run we do want protection from active attacks, and a way of getting that deployed, and enabled by default, and yet not disrupting communication when not under attack. Perhaps I should expand the example section to explain opportunistic DANE TLS for SMTP (even if that spec is still some weeks from LC), not just opportunistic TLS. Then people might have a better understanding of how opportunistic authentication works with DANE, and should work generally. I don't want the draft to over-emphasize DANE, it not just about DANE, but leaving out that example may have resulted in text that is a too abstract. -- Viktor.