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.