[TLS] Non-TLS opportunistic encryption

[Phillip Hallam-Baker <[e-mail]>]

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.