HTTP/2.0 draft, NPN/ALPN, and TLS

I see from the archives that there has already been some discussion on
this subject; I wanted to add my 2 cents and proposal.

Problems with upgrading to HTTP/2.0 using NPN/ALPN:

1. NPN/ALPN is not supported in many development frameworks. Especially
Java doesn't even have it on the roadmap for the next version, it's been
reported as an issue but is currently not even assigned. Python does
have it but only since 3.3. This will harm uptake since it will take a
long time to even start development and even when that's happened, many
deployment environments cannot be upgraded to the latest whizzy
features. The only solution for developers is to create their own entire
TLS libraries and deploy those, which creates fragmentation, and
introduces a high probability of error and security vulnerability.

2. the mechanism for upgrading plaintext HTTP and HTTP over TLS is
assymmetric. This adds unnecessary complexity.

Confidentiality is an important desired property of next generation
Internet protocols. However, I would argue that the correct place to
implement it is in IPsec rather than the TLS layer. This lowers the cost
of all applications, not just HTTP. Eventually (hopefully sooner rather
then later) the carriers will pull their fingers out and actually
implement IPv6, and then IPsec will basically be standard. That's the
future we want to be looking forward to, rather than trying to reinvent
everything at every single level of the stack. When your connection is
secured with IPsec, TLS is redundant and a duplicated waste of effort,
so it should be dropped. This means that the primary focus should be on
the "plaintext" HTTP protocol.

Obviously that isn't going to happen overnight, however it may well
happen before there is widespread deployed support for the current
NPN/ALPN proposal. In the meantime we want a confidentialy solution that
works. I propose that there be a standard STARTTLS-like HTTP Upgrade
mechanism that can convert the plaintext HTTP connection (on port 80)
not only to HTTP/2.0 but also start TLS. This allows one port to
negotiate everything and makes running servers on separate ports
especially for TLS redundant. When this has happened, operators can
decide to remove TLS completely from the equation as it becomes
redundant itself in the wake of IPsec. No need for a multitude of
special magic port numbers especially for TLS versions of existing
protocols. There is no more HTTPS, just HTTP.

The Upgrade mechanism should be able to be implemented using existing
widely deployed languages and frameworks.

Received on Monday, 9 December 2013 18:20:06 UTC