On 8/6/2014 7:30 AM, Viktor Dukhovni wrote: > 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. In terms of legitimate need for a term and likely use of it, I suggest that it is seriously misguided to believe that this term will be used only by that extremely restricted community. They'll make the technology > available to users, but users also need a vocabulary to understand > what they are getting. Exactly. Your earlier recitation of TLS as an example of why saying 'security' is ok is indicative of the problem here. The severely limited real-world uses of TLS is widely misunderstood amongst users. They hear the word security and believe all sorts of protections are in force that rarely -- or never -- are. Even in IETF discussions, the fact that client authentication is essentially never done is an example of the problems caused by sloppy, vague terminology. >> 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. Viktor, Stephen was providing a broad-based and conceptual description of the term that covers a wide variety of uses. The only place that's going to happen is in this definition. What will happen in specifications for particular protocols will be about particular protocols. They will not -- and must not -- be making broad statements of the sort that Stephen made. >> 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. An unfortunate effect of small-group dynamics is that it's members can develop a shared sense of things that is widely at variance with what th rest of the world will see and understand. The challenge, then, is to treat publishable statements with skepticism and put effort into considering how they will be seen by those not already familiar with the language. So I do understand that your view is what some of you have convinced yourselves of. However it is not what I'm seeing in the different statements. >> 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. Forgive me but this response seems a non-sequitor to me. I do not understand how it is relevant to the concerns I've raised or suggestions I've made. >> 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. It's always self-comforting to choose an ad hominem counter-argument. Please try to refrain from repeating that indulgence. > 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. I do acknowledge that you are not seeing the problem I am asserting. >> 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. We have? What consensus process was that? This is an individual submission. The repeated citation of previous discussions in saag, as if they resolved issues, is a basic and serious error in IETF process. > If we keep revisiting every decision, we'll never be done. Casual dismissal of basic concerns might produce output, but it will be problematic output. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net