Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt

[Daniel Kahn Gillmor <[e-mail]>]

On 02/03/2014 02:19 PM, Alan Johnston wrote:
> On Mon, Feb 3, 2014 at 11:29 AM, Daniel Kahn Gillmor <[e-mail]>wrote:
>
>> Opportunistic encryption as declared by the draft is encryption that
>> *will* fail against an active attacker or MiTM.
> 
> I don't think that is a good way to define opportunistic encryption.
> 
> In my view, the opportunistic property of encryption (whatever we decide it
> is) should not be conflated with authentication via a PKI, or PFS, or any
> other orthogonal security property.

You'll note that i'm not defining it according to any of these specific
properties.  In particular, it's possible that a remote peer can use
PFS, with a cartel-issued X.509 cert, using AES-GCM and TLS 1.2, and
still be considered opportunistic.  Why?  Because if the same connection
had *not* had any of the above properties, the local networked
application would have gone ahead with the connection without them (even
to the point of making the connection in cleartext).

> We need a definition of opportunistic that distills it down to the minimum
> so we can talk about it sensibly.  The first sentence of Section 2 of
> Paul's draft is an excellent start to the definition.
> 
>    An application supports opportunistic encryption using TLS if the
>    application attempts to perform TLS negotiation without the user who
>    is running the application knowing whether or not TLS is in use.

I think the more salient property for "opportunistic" encryption is that
it is not forced to "on", and that the connection would continue
(perhaps unencrypted) even in the presence of an active attacker.  As
such, i agree with Paul's assessment that it makes no sense to display
this state to the user -- even if they happen to be encrypted on the
current connection, a subsequent connection the same options/choices
could easily be forced to cleartext, so it is not "secure" in the
traditional sense.

If an opportunistically-encrypted HTTP client receives from the server
the following headers:

  301 Moved Permanently
  Location: https://example.org/foo

, then the server is signalling that it is moving out of opportunistic
mode, and all the normal (non-opportunistic) rules should apply to the
subsequent https:// connection, and therefore the user-facing signalling
can be displayed on these subsequent connections.

> I think this is the opportunisticky property that we need a good working
> definition.  However, in the next paragraph, sentences such as this, don't
> help:
> 
>    When an application that supports opportunistic encryption negotiates
>    TLS, that application might or might not authenticate the TLS server.
> 
> That is true, but it is irrelevant to the definition.  An opportunistic
> encryption system might also use PFS, do logging, cache keys, or any number
> of other things.  We need separate definitions for each of these, and not
> conflate them together. Otherwise, we can't make any sensible
> recommendations about opportunistic approaches, especially when different
> people conflate different things and use the same word.

I disagree that this is an unnecessary distraction, given the current
state of TLS on the web.

Many web sites fail to deploy TLS today because of one of two reasons:

 0) they have multiple sites hosted on the same webserver or CDN,
sharing an IP address, and they cannot expect all clients to offer SNI
(thanks to IE and Safari on Windows XP).

 1) they have administrators who balk at the cost or confusion or
ongoing maintenance hassle of getting an X.509 certificate from a member
of the CA cartel.

It is useful to clarify that neither of these constraints should
necessarily limit deployment of opportunistic TLS for the web.

	--dkg