On Fri, Jul 25, 2014 at 06:19:34PM -0400, Dave Crocker wrote:
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 term "opportunistic security" is defined as an umbrella term,
so if "security" is an umbrella term, there is no conflict. I
should note that "TLS" is "transport layer security", not "transport
layer encryption", and TLS also can be used for a range of capabilities
ranging from:
$ openssl ciphers -v 'eNULL+aNULL'
AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1
which provides only message integrity (without authentication!) all the
way to bleeding-edge:
# openssl ciphers -v 'kECDHE+aECDSA+AESGCM+AES256'
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
Mac=AEAD
which given a suitably secure selection of curves provides PFS,
ECDSA authentication, and strong encryption with authenticated
message integrity.
Given the long discussion on [saag], I think we have rough consensus on
"opportunistic security" as an acceptable choice of name.
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.
I'll do whatever it takes to emphasize that the definition is NOT
to be mistaken for just "encrypt when possible" (without authentication).
The term is intentionally *opportunistic security*, not just
mitigation of passive intercepts.
In particular, one important example of "opportunistic security"
is opportunistic DANE TLS in the DANE WG SMTP draft. Here for
domains that publish DNSSEC "secure" MX records and TLSA RRs for
the associated MX hosts, the client authenticates the SMTP server
and the protocol is resistant to various MiTM/downgrade attacks.
And yet it is opportunistic, because DANE authentication applies
when possible, and otherwise the SMTP client employs legacy
opportunistic TLS, which may even transmit in cleartext when
the peer does not appear to support STARTTLS.
It is my hope that promoting "opportunistic security" not be
tantamount to promoting abandoning authentication. Sure we
want to *at least* encrypt, when possible, but that is *not*
the maximal security we should aim for. We should be looking
to deploy protocols that offer a range of capabilities, and
should deploy designs in which peers strive to eke out as
much security (umbrella term) as possible.
2. The document says it is providing a definition, but it does not
do that. It needs to.
Here I am open to improved language that sums up the design principles
characteristic of opportunistic security into a definition. We
should be mindful of the fact that the term is an umbrella term,
and the "definition" cannot precisely define behaviour, rather
it needs to define a design approach.
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.
Suggestions to the specific language that make the definition more
clear are definitely welcome. I am not ready to adopt the above
text in preference to the current version.
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.
Protocols that employ opportunistic security may include fallback
to cleartext, where necessary for interoperability with existing
or unavoidably less capable systems. If there are specific places
where this is unclear, I'd be more than happy to clarify.
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.
Opportunistic security is an umbrella term for protocol designs
that strive to interoperate at the maximum available "security"
with a given peer. Once we have some specific form of encryption,
or authentication, the adjective "opportunistic" is no longer
applicable. "Opportunistic" is about the willingness to find a
mutually agreeable security mechanism, it is not the mechanism
itself once the choice is made.
Therefore, I am advocating essentially the opposite view. Encryption
is just encryption, it may or may not be unauthenticated.
Opportunistic security is a flexible policy, which may leads to
encryption, possibly authenticated, or may lead to cleartext.
Neither cleartext, nor unauthenticated encryption, nor authenticated
encryption are "opportunistic".
4. The draft's references to authentication are almost certainly
meant to be limited to server-side authentication.
No. There are potential opportunities for opportunistic authentication
of clients also, exploring this question in the context of DANE is
part of the new DANE WG charter.
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.
A recent discussion of the draft mentioned "strategic ambiguity",
I think it is relevant here. We're not circumscribing the capabilities
of the peers or limiting the scope of security services that
opportunistic security can provide.
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.
The intention is that "strong" means roughly comparable to the
protection provided by existing non-opportunistic designs, thus
generally resistant to most passive and active attacks. Some
strategic ambiguity is also appropriate here.
--
Viktor.