Subject: [TLS] Non-TLS opportunistic encryption

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Jul 2014 12:28:56 -0400

While at the Hope conference watching the 'HTTP must die' presentation
I had an idea that might or might not be useful.

People frequently propose use of opportunistic TLS with self-signed
credentials. This worries me for two reasons:

1) TLS is a huge standard with a lot of details that have to be got
right. It takes a lot of time and effort to implement and a lot of
memory to run. Constrained devices are going to find it very hard to
do TLS

2) One consequence of (1) is that opportunistic TLS risks weakening
the https infrastructure rather than improving the http
infrastructure. That is not a win as far as I am concerned.

So one proposal that is made is to drop the padlock icon when
non-credentialed self-signed certs or keys passed in band are in use.
This seems a very good approach to me but we still have the problem of
it being a 'thick stack'.

This is even more problematic when we consider the fact that most of
that 'thick stack' is actually involved in addressing issues that just
don't apply if we are not going to validate the end-entity-keys.

Self-signed certs are a reasonable way to exchange keys in a world
where the infrastructure has ubiquitous support for X.509 path math.
But why clutter up the client with the path math if we are not going
to check cert chains?

If we are going to insist on 'encryption everywhere' and accept
opportunistic encryption then all we need is a D-H key agreement and
some mechanism for applying encryption to packets.

The result might be TLS-Lite, a very minimal subset of TLS or it might
be a completely different protocol. But the key thing would be to keep
it separate from TLS so that ubiquitous best effort TLS does not end
up weakening regular TLS.

---

From: Tom Ritter <[email-masked]>
Date: Mon, 21 Jul 2014 12:17:40 -0500

> up weakening regular TLS.

It's not clear to me exactly what you mean by 'weakening regular TLS'
- I'd also disagree that opportunistic encryption should get any of
the UI indicators that TLS gets.

I'm not sure if Opportunistic TLS is still on-topic for this list, but
the primary concern I've seen people put forward (and agree with)
about Unauthenticated Ciphersuites or a DH handshake is that with
self-signed certs - you can build a Convergence-style in-line
authenticity system or a CT-style after-the-fact detection system on
top of it.

With the other options, you lose that capability.  And if you try and
shoe-horn a long-lived signing key on top of that, you've reinvented
some subset of TLS+PKIX - why not just use that subset and not require
any (significant) server code changes.

-tom

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jul 2014 12:43:32 -0700

> infrastructure. That is not a win as far as I am concerned.

I'm struggling with your premise.  I don't think that either is really true.

Yes, TLS is complex, but inventing a new protocol sounds like a cure
that is worse than the disease.

I don't know if you are aware, but there is this:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-00