On Wed, Aug 06, 2014 at 06:43:56AM -0700, Dave Crocker wrote: > All of the above means that this term is for use only by security > experts, since it makes the term unwieldy for use by anyone else. The draft's core audience is designers of security protocols, and implementors of protocol toolkits. They'll make the technology available to users, but users also need a vocabulary to understand what they are getting. Postfix has had support for "opportunistic TLS" since at leeast 2006. There has been little user confusion. In January 2014 we added "opportunistic DANE TLS", and still no user confusion. Perhaps users will understand the concept more easily in the context of their particular application and its documentation. > I'll also note that the draft says nothing like the above. That should > bother you, and everyone else. More accurately, the draft leaves some things unsaid, that can only be made concrete in a particular protocol that makes the appropriate choices. For example, there is a common myth that in client-server protocols authentication of the server by the client and authentication of the client by the server have essentially similar semantics. This misconception is especially common with regard to TLS, where I've observed that many users believe that if authentication of the server by client can protect against active attacks, then surely so must authentication of the client by the server even absent the client authenticating the server. This is false. Sloppy reasoning about the security properties of protocols leads to nonsense. So I focused on what could be said about opportunistic security, and left out what could not be said. Perhaps some disclaimers belong in the text. Perhaps the text can be made clearer, I wonder what it is specifically that makes the text clear to Scott K., but fails to get the idea across to you. If you could highlight where I've lost you, perhaps the text can be improved. > Worse, the different responses from folks who have been active in the > discussion and who try to explain the term show different > understandings/meanings. Still. After all this time and discussion. Different words, same tune. > The only "end-to-end" protection function that has been seriously > discussed is confidentiality through encryption. All other protections > really have no concrete basis in practice or even in discussion focus, > within the context of this 'opportunistic' framework. This is clearly not the case. Multiple people have expressed some concern that even the draft's definition of OS makes it too easy to weasel out, implement only opportunistic unauthenticated encryption and stop there, ignoring active attacks entirely. They and I want more than that, and in fact we have a soon to be published and already deployed (small number of early adopters so far, gated by currently low deployment of DNSSEC) protocol "SMTP opportunistic DANE TLS", that does more. > Of the various terms that were originally suggested, the one that has > the simplext, clearest and most useful meaning is "best effort". > Opportunistic is clearly a much sexier word, but the continuing lack of > coherent community understanding of its meaning makes it problematic. At > the least, it means that it will not be particularly intuitive for the > rest of the world. Perhaps you're projecting your own surprise at the meaning of the term onto the community at large. Yes, I would like the draft to be accessible to all, and we may yet need to revise it to be more clear, but I don't think there's a broad failure by the community to understand the term. It seems that most people are able to express the same ideas in their words and still end-up saying the same thing. Ideally, we can increase the size of that purported "majority". > In contrast, best effort is a commonly used term and it means exactly > what is at issue here, as the common thread to everyone's attempted > explanations. > > To the extent that folks really can't abide having the term be focused > specifically on encryption, then focus on the functional component that > is also common to everyone's explanations: key management. How the key > is administered is the essence of what the current topic is focused on. > > Best Effort Key Management If "best effort" is the right prefix, it is still "best effort security", not "key management". But "best effort" misses the point, and we've already chosen a term by rough consensus, and any problems with the draft are with its wording, not the term chosen to be defined. If we keep revisiting every decision, we'll never be done. I would like to suggest strongly that we let "OS" stand, and focus on the clarity of the definition instead. -- Viktor.