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

See below.

On Mon, Feb 3, 2014 at 11:29 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net>wrote:

> On 02/03/2014 12:13 PM, Alan Johnston wrote:
> > But it's the "ignore any server failure" part that is the security
> > reduction, and that is not OE by your definition but "unathenticated TLS"
> > that you describe in the Appendix, right?
> >
> > Here's a real example:  The EFF's HTTP Everywhere browser extension (
> > https://www.eff.org/https-everywhere).  It finds HTTPS connections even
> > when I just try to visit the HTTP site.  Does the browser displaying the
> > padlock hurt anything?  How does this reduce security for the Internet?
>
> https-everywhere (HTTPS-E) deliberately only includes rules for sites
> which are believed to have a non-expired, valid X.509 certificate that
> was issued by a member of the CA cartel, using standard https://, and
> for which the content served over http is expected to match the content
> served over https.  HTTPS-E also *enforces* HTTPS access, so if the web
> servers for the sites flagged by HTTPS-E were to stop listening on port
> 443 or to stop negotiating TLS in the first place, (or an MiTM were to
> make it look this way), the browser's connections to those sites would
> break.
>
> In these contexts, where the user is not vulnerable to an MiTM,
> displaying a lock is reasonable, and is *not* what Paul is warning
> against, if i understand the draft correctly.
>
> 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.

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 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.

- Alan -

>  It would be bad for the
> 'net if our tools were to indicate that MiTM-able connections are
> "secure" using the same UI as non-MiTM-able connections.
>
>         --dkg
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>