On Fri, Aug 15, 2014 at 08:54:18AM -0700, Dave Crocker wrote: > > Designing and deploying a key management for the whole Internet is > > for now an unsolved problem. Oops the word "system" got lost after "key management"... Will have to add that back when I next get a chance. > > The opportunistic security design pattern involves stepping up from a > > baseline security policy compatible with all relevant peers to the > > most secure policy compatible with the capabilities of a given peer. > Actually, it involves stepping /down/. The draft is providing a *definition*. Definitions should be taken at face value. This is not an empirical statement whose truth one can debate, it is a definition. > > A related goal is broader adoption of protection against active > > attacks, by enabling incremental deployment of authenticated > > encryption. > > Although this sounds entirely reasonable, there is no explanation > provided to make it credible. (n fact it is not at all clear to me that > is /us/ credible...) How will use of an opportunistic pattern lea to > broader adoption? By enabling deployment that is incremental and yet on by default. With "all or nothing" security there is no way to allow the network effect to help reach near-universal adoption. > > Both opportunistically > > employed encryption and opportunistically employed authentication > > need to avoid deployment roadblocks and need to be designed with care > > to "just work". > > I have no idea what the last sentence means. It means mechanisms that consistently work out of the box, no need to tune explicitly for each peer or prompt the user when they predictably fail a significant fraction of the time. > > Opportunistic security does not start with an over-estimate of peer > > capabilities only to settle for lesser protection when a peer fails > > to deliver. Rather, opportunistic security sets a minimum protection > > level expected of all peers, which is raised for peers that are > > capable of more. > > This paragraph is not very helpful. The issue here has nothing to do > with estimation. (Can a design pattern make an estimation?) An estimate is what one has, when one has not ye performed the measurement. Perhaps a better word could be crafted here, suggestions? I still think the original text is sufficient. The first sentence is what you're consistently not taking at face value, the point needs to be made. > If authentication is required, we have classic authenticated encryption, > not opportunistic <foo>. Again no, you're still reading what you would have said, rather than what the draft actually says. The draft actually defines a way to do "opportunistically employ" authentication. And this is important, and is the main point of departure from Steve Kent's earlier draft. "Required of all peers" is not opportunistic. Required when advertised By a given peer > The 'opportunistic' construct is all about permitting lesser protection. > If it isn't permitted, we are not in an opportunistic scenario. Again, that's not the *definition* in this draft. You might have defined it that way, but this draft does not. > The term needs to be quite disciplined about what is excluded and what > is included. As soon as the term is too broad, it is meaningless. No, not meanigless, just not the meaning some would have come up with. > > Enforcement of authentication is not incompatible with opportunistic > > security. If an OS-enabled peer (A) makes available authenticated > > key material, e.g., via DANE, to peer (B), then B should make use of > > this material to authenticate A, if B is OS-enabled and supports > > DANE. > > This is worded a bit differently than in the preview draft I saw, but I > still have no idea what that sentence means. The language that follows > is about preference, not enforcement. > > Ultimately I can't tell what the motivation for this sentence is. You're still not reading the definitions as stated. > > If authentication is only possible for some peers, then it is > > acceptable to authenticate only those peers and not the rest. > > It is only sometimes acceptable. It is essential that the text here > highlight that such a fallback needs to be the result of careful > analysis and choice and not a casual default. There is no fallback from a suitably advertised capability to be authenticated (e.g. via DANE). Similarly the TACK draft is a type of opportunistically enabled authentication that is more of the TOFU style. > > > > Employ PFS: Opportunistic Security should employ Perfect Forward > > Secrecy (PFS) to protect previously recorded encrypted > > communication from decryption even after a compromise of long-term > > keys. > > I'm told that PFS isn't really possible for asyncrhonous, object-based > encryption, such as for email. PFS works for hop-by-hop SMTP, but yes, not likely for end-to-end S/MIME or PGP. This could be qualified with "when possible" or some such. > > No misrepresentation of security: > > > > Unauthenticated encrypted communication must not be misrepresented as > > communication over a secure channel. > > Oh boy. That sentence is far too compact and not obviouly correct. In > fact it is arguably wrong. That's the -02 draft text you're responding to. > > In summary, the opportunistic security design pattern encompasses > > protocol designs that remove barriers to the widespread use of > > encryption on the Internet. The actual protection provided by > > opportunistic security depends on the advertised capabilities of the > > communicating peers. Opportunistic security aims to encrypt all > > network traffic, while allowing fallback to cleartext with peers that > > do not appear to be encryption capable. > > Ran out of time. Haven't reviewed the remainder... So is this. > > > 5. Example: Opportunistic TLS in SMTP > > > > Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS > > ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are > > generally willing to send email without TLS (and therefore without > > Software does not have a 'will'. I think what is meant here is 'able'. Except that we're describing tolerated lower-bounds, not abilities. > > Therefore, MTAs that implement opportunistic TLS either employ > > unauthenticated encryption or deliver over a cleartext channel. > > deliver -> transmit Sure. > > Recent reports from a number of large providers suggest that the > > majority of SMTP email transmission on the Internet is now encrypted, > > and the trend is toward increasing adoption. > > This anecdotal comment isn't needed, isn't substantiated, and is going > to be distracting when this document is read 20 years from now. I > suggest removing it. The example is an anectote, a protocol case-study if you like, not a specification. It is I think useful to highlight a success of OS in this space. > > > Not only is the STARTTLS advertisement vulnerable to active attacks, > > but also at present some MTAs that advertise STARTTLS exhibit various > > interoperability problems in their implementations. As a result, it > > Again, the ephemeral frame of refernce won't be helpful. > > So: > > but also an MTA that advertises STARTTLS can produce various > interoperability problems in its implementation. As a result, it might > choose to fall back to cleartext... Except that the wisdom of the cleartext retry is rooted in the operational status-quo. When the interoperability issues with clunky old MTAs fade away, the engineering trade-off will be different. > > 6. Security Considerations > > > > Though opportunistic security potentially supports transmission in > > cleartext, unauthenticated encryption, or other cryptographic > > protection levels short of the strongest potentially applicable, the > > effective security for peers is not reduced. If a cryptographic > > capability is neither required by policy nor supported by the peer, > > nothing is lost by going without. Opportunistic security is strictly > > stronger than the alternative of providing no security services when > > maximal security is not applicable. > > I'll repeat that counting "cleartext" as part of an opportunistic > pattern is a strategic error. In simple terms, it is saying that no > security is part of security. Yes, in order to make security usable, we tolerate no security as a baseline where required. > The issue is not that cleartext is bad or that permitting it might not > be ok. It's that it needs to be outside of the scope of an > opportunistic pattern. Disagree. Otherwise we get into "fallback" and all that, but OS is about attempting to get more than minimum (possibly none) security. Not about settling for less. As defined! Not empirical fact to debate. You could argue for a different definition, but it should be clear that you'd prefer a different formulation, not that the current one is "wrong". > > Opportunistic security coexists with and is preempted by any > > applicable non-opportunistic security policy. However, such non- > > This first sentence makes no real sense to me or worse is confusing. It > does not "coexist". If it is preempted, it is at best subordinated. Well, coexists and is subordinate to. But that is clearly evident from the text... -- Viktor.