On 7/8/2014 11:09 AM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Opportunistic Security: some protection most of the time'
> <draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
...
> Abstract
>
> This memo defines the term "opportunistic security". In contrast to
This document will be important. Overall, it is a reasonable discussion
of a timely and useful construct. It's basic organization and basic
writing are reasonable, although it does need additional and diligent
wordsmithing. (I will send those suggestions to the author separately.)
However the document is not yet ready for publication. It suffers a
number of significant deficiencies that need to be remedied. I believe
all of these have been cited by others, but here are my characterizations:
1. In a technical context the word 'security' is, at most, an
umbrella term that encompasses a range of possible capabilities, such as
integrity, authentication, encryption and so on. By itself, the word
has no technical meaning, other than as a reference to an "area" of
technical work.
Consequently the term "opportunistic security" falls somewhere
near the intersection of meaningless, confusing and wrong. We do not
serve technical or non-technical communities well by using terminology
that is so vague or misleading (or both.)
The actual focus of the draft is encryption and -- unless I've
significantly misread the draft -- the term that covers what is
discussed therefore should be "opportunistic encryption".
I believe at least one other note did raise the possibility that
the term might /also/ include authentication -- distinct from
encryption. While that's a reasonable idea on its own, it does not
appear to be consonant with any of the discussion around opportunistic
encryption. So I suggest it be deferred.
The topic of this draft needs to be changed to "opportunistic
encryption".
2. The document says it is providing a definition, but it does not
do that. It needs to.
What it does do is to provide an extended discussion of the
topic. The discussion is useful, but it is not a definition.
Viktor has commented on this concern with:
> The definition is a summary of the design principles.
This is the second major security-related document to assert such
a philosophy for a denotation exercise. However a definition is a few
sentences; it is not multiple pages. When the text gets into multiple
pages, it is a specification or a discussion. It is not a definition.
Fortunately, the draft provides some text that looks like a good
basis for a definition, which I've mildly reworked into:
Opportunity encryption is an umbrellas term for efforts
to increase the use of encryption by permitting variable
protection strength during a session. It attempts to use
the strongest capability possible, but permits falling back
to a weaker option. In particular it permits the use of
unauthenticated encryption when authentication is not
available.
The phrasing "variable protection strength during a session" probably
needs improvement...
3. The draft variously permits or prohibits use of cleartext within
the context of the defined term. This needs to be resolved, and carefully.
My own sense from the saag discussions and the draft is that
there is tendency to conflate 'what opportunistic encryption is' with
'what is permitted in a session that attempts opportunistic encryption'.
It other words, it is confusing the thing with the context in which the
thing is occurring.
For simplicity and utility, I suggest that the term opportunistic
encryption always refer to actual encryption, with the note that when no
encryption is possible in a /session/ it might be permitted to fall back
to cleartext.
4. The draft's references to authentication are almost certainly
meant to be limited to server-side authentication. That is, the
authentication that is attempted is of the side being contacted. As I
understand actual Internet practices, mutual or client authentication is
typically NOT part of the process when setting up authenticated
encryption. This needs to be clarified in the text.
5. The document uses the term 'strong' as a form of protection, but
doesn't really define it. However it seems to be used with some
significant meaning intended. The term gets used frequently an casually
about security, but here it seems to be intended to have a specific
meaning. That meaning should be provided explicitly.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net