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.