----- Original Message ----- From: "Viktor Dukhovni" <ietf-dane@xxxxxxxxxxxx> To: <saag@xxxxxxxx> Cc: <ietf@xxxxxxxx> Sent: Wednesday, July 30, 2014 4:08 P > On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote: <snip> > I like "all or nothing", "all" here is sensibly read as "everything > implemented", not "everything possible". Thus simply a binary choice. > > However, in trying to work this into the text I am finding that it > becomes more verbose, and spends too much time on inessential > details. Perhaps this is just failure to craft the right text on > my part, but I am having a hard time actually improving the text > overall, even though "all or nothing" is perhaps better than "strong". > > There is a tension here between a quick informal description of existing > practice, that should be clear to most, with a clear focus on the new > model, and a more accurate/detailed description of past practice, that > might detract from the focus of the document. > > Is anyone willing to take the time to carefully update the Introduction > to find the sweet spot between the current cursory nod to the past on > one extreme, and potentially an overly elaborute detour on the other? > > I tried a couple of times, but have not yet succeeded. Writers > block and shortage of cycles perhaps... How about " Opportunistic security encourages peers to employ as much security as possible, without falling back to unnecessarily weak options. In particular, opportunistic security encourages unauthenticated encryption when authentication is not possible. Without key management at an Internet scale, authentication is often not possible. When, as a result, protocols only offer the options of either strongly authenticated secure channels, or else no security, traffic commonly gets no security. Therefore, in order to make encryption more ubiquitous, authentication needs to be optional. When strongly authenticated communication is not possible, unauthenticated encryption is preferable to clear text. Historically, Internet security protocols have prioritized strong protection, for peers capable and motivated to absorb the associated costs and this has lead to most traffic being unprotected. The fact that most traffic is then unprotected facilitates pervasive monitoring (PM [RFC7258]) by nation states, by making such practices cost-effective (or, at least, not cost- prohibitive). Such indiscriminate [widespread?] collection of communications traffic would be substantially less attractive to nation states if security protocols offered a range of protection levels, offering encrypted transmission to most, if not all, peers and offering stronger security when required by policy or by opportunistic negotiation. Encryption remains easy, key management is difficult. Key management at Internet scale is an incompletely solved problem. The PKIX ([RFC5280]) key management model introduces costs that not all peers are willing to bear and also cannot secure communications when either the reference identity of the peer is obtained indirectly over an insecure channel or the communicating parties cannot agree on a [root?] certification authority (CA). Thus DNSSEC is not at this time sufficiently widely adopted to make DANE a viable alternative at scale, while trust on first use (TOFU) key management models (such as with saved SSH fingerprints and various certificate pinning approaches) fail to protect initial contact; and, also, require user intervention when there is a failure of key continuity. " I think that the paragraph order is key! Currently it is deductive, fine for academic texts, less so for RFC, hence my switch to inductive. Tom Petch > > I think that if we change nothing, though the document could likely > be improved, that the improvements are inessential. Perhaps we > can leave well enough alone? > > -- > Viktor. > >