Hi Dave, Well, its a terminology draft, so I'll comment on one term you used below in the hope that helps clarify a bit more of this:-) On 06/08/14 04:28, Dave Crocker wrote: > Focusing on a "framework that permits decreasing levels of encryption > protection" or similar language resonates with what I've been reading > about this opportunistic thing. (My own view is that cleartext has no > place within that hierarchy, so some sort of minimum encryption needs to > be described. Hierarchy isn't the right concept here. There are different states that might result after some opportunistic security steps are taken in a protocol. Those include having fallen back to cleartext, encrypting with zero, one or both endpoints authenticated and many variations in terms of how endpoints can be authenticated (DANE, "traditional" x.509-based PKI, TOFU, etc. etc.). One could also extend to more than two endpoints but let's omit that for just now. There are also interactions between all the above and the particular protocol we're trying to secure, e.g. IMAP/TLS is quite different from MTA-MTA with STARTTLS and both differ from the putative MPLS thing Adrian and I have sketched out. Its very important to note that there isn't even a partial order of the various end states on which we can always generically agree, never mind a full ordering. For example, would client or server authentication be "better" or DANE vs. TOFU? In general, we cannot decide. Its not that we're being lazy, but in this case your mileage really will vary in ways we cannot decide in the abstract. So a hierarchy isn't the right way to think about this. That's one of the things that makes this tricky to describe, even after we've all understood and agreed on what we really want to describe. However, we do believe that each protocol that uses OS techniques can be analysed so as to produce a sensible description of which states are ok, which (if any) are not ok and hopefully at least a partial ordering of the end states in terms of preference, or perhaps just in terms of what gets logged. (That last can be more powerful than one might expect btw.) Our history is that we mostly didn't allow for OS, either in protocol design, nor in implementations, although some protocols that we did design can already support OS if the implementations want it, e.g. MTA-MTA SMTP over TLS. This draft legitimises using OS in future protocols or in current ones where implementations can play the OS game. From my POV, doing that is important both when considering BCP188 issues, but also in terms of overall improvement in deployability of the security mechanisms we build into protocols. Hope that helps, S. PS: I'm just back from vacation and won't get to reviewing the last call comments for a day or two. Even though the IETF last call is officially done, please do continue to discuss this. (And thanks for both the content and tenor of the discussion to date!) When I've reviewed all the comments, I'll come back to the list with what I think is the right next step - that could be trying to get some of the folks who've commented into some form of offlist huddle for a few more days and then returning with that text for all to check, but as I say, it'll be a couple of days until I've caught up.