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