Dave,
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.
since we're trying to be precise, those are called "security services."
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.)
I believe most folks now agree that it's a marketing term, and thus suffers
from the shortcomings you note.
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".
My doc, which pre-fdated this one, provides an extensive explanation
for why the term "opportunistic encryption" is not technically appropriate.
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".
preferably not.
2. The document says it is providing a definition, but it does not
do that. It needs to.
agreed, and I offered one a few weeks ago.
What it does do is to provide an extended discussion of the
topic. The discussion is useful, but it is not a definition.
agreed.
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.
I concur and agree that a real definition is needed.
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...
agreed.
3. The draft variously permits or prohibits use of cleartext within
the context of the defined term. This needs to be resolved, and carefully.
I would say:
"OS strives to greatly broaden the use of encryption in IETF protocols,
to combat PM. To facilitate incremental deployment, OS operates in
a fashion that may result in a plaintext connection/session."
...
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.
Typically true for TLS; not true for IPsec, not true for SSH, ...
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.
agreed.