MLS or TLS? There is more than one encryption option.

I have heard all the tactical reasons for wanting TLS as a mechanism for
proxy busting. I do not accept these because however awful people think
proxies are, they were invented for a purpose.

Moreover I think that people are ignoring many of the practicalities of how
TLS is supported by commercial providers. Whether you like the business
models of the ISPs or not, there will be no deployment of HTTP 2.0 without
them. Most ISPs provide HTTP 1.0 and DNS names at or below cost. Their
primary means of making profits is to sell premium services. The only
premium service that has not ended up being commoditized is selling SSL/TLS
certificates.


>From a technical point of view, TLS has two major impediments, first the
stack is huge and proposing to use a subset does not make things any
easier. The only part that can be easily separated from the rest is the
PKIX stack but separating out all the dependencies would be many years of
work for most of the systems out there. It really would be easiest to write
a TLS-Lite stack from scratch rather than try to cut down the existing
libraries.

And that is before we get to the fact that it would take five years to
agree on what TLS-Lite should contain.

I propose that we go a different route for preventing pervasive
surveillance, one that protects the HTTP content against a passive attack,
has negligible additional overhead other than the actual encryption cycles
and is compatible with the existing semantics of TLS.

>From a marketing point of view I think the group is shooting itself in both
feet (and other parts) with its message that HTTP/2.0 is much faster than
HTTP/1.0 until you use the mandatory encryption which makes the transition
a wash.


It is quite easy to design a scheme that has these properties with a small
fraction of the complexity of TLS-Lite. All that is required is a
lightweight key exchange in the headers plus a Content-Encrypted header.

I have even written code for such a scheme recently, albeit with Web
Services in mind. This is the scheme that I subsetted to come up with the
HTTP Session-ID proposal:

https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/


This draft does not have the DH key agreement or the encryption described
but the code works and the whole package is only about 300 lines of C plus
whatever the crypto libraries need (my estimate may be off as I write in
C#).

I took the encryption layer out for two reasons. First I thought it might
shoot the chances of getting a standard in the IETF. But the more important
reason was that I wanted to keep that capability as a silent, latent
capability that could be turned on in case of future need such as another
Arab Spring situation.

Now that we are going to be going for preventing pervasive surveillance, I
think we should add a Message Layer Security scheme to HTTP to complement
TLS. In cases where the initial key exchange is supported by TLS, we can
use channel binding to connect the two. We can also provide a mechanism to
authenticate the MLS layer (which would be optional). But either scheme
could be used independently.


The advantage of using MLS and TLS in combination is that they both serve
different security requirements.

Pervasive encryption is a good idea but not if the cost is to weaken the
security of a deployed system that works.
We already have a TLS system that works well. I have no objection at all if
the HTTP-BIS WG wants to mandate use of TLS with the WebPKI. But I don't
think that is what is being proposed.

What I think is being proposed is to wreck the only widely deployed
security infrastructure that we have today by offering a 'lite' version
that busts holes in the trust model. And that is not going to happen.

-- 
Website: http://hallambaker.com/