Most Internet Engineering Task Force (IETF) debates pass unnoticed, because they're very dry and detailed. However, a suggestion that the HTTP 2.0 specification might mandate encryption – in a post-Snowden world – is too tasty an idea to go under the radar.
The suggestion sparking the debate came from HTTPbis chair, Mark Nottingham, who put forward a discussion summary in which he suggested some kind of consensus is emerging that HTTP 2.0 should favour https:// to protect users (to some degree) against traffic snooping: “HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1 (and of course it would still be possible for older HTTP/1 clients to still interoperate with https:// URIs)”, Nottingham wrote on the IETF HTTP working group list.
Other options he reported from the IETF Vancouver meeting were to use opportunistic encryption for http:// URIs without authenticating the server; or to add server authentication to the opportunistic encryption suggestion.
It's regrettable that the story has turned into a “W3C wants to encrypt HTTP 2.0 by default”, because what's more interesting is the strength of feeling that accompanies the debate.
Nottingham's e-mail sparked two things: headlines giving the “SSL-only” idea a stronger status than it has; and a strong debate on the list about the merits of the proposal.
Since the ongoing debate is a clear indication that Nottingham's proposal wasn't any kind of a consensus position, but rather a summary of discussions, The Register would like to focus on how the list seems to see the pros and cons of the idea.
Would “mandatory” SSL make the Internet more secure?
Obviously the starting point is that if it were adopted – that is, HTTP 2.0 sites default to secure sockets layer (SSL) using transport layer security (TLS) as the mechanism, it would only impact HTTP 2.0 servers communicating with HTTP 2.0 browsers. Someone with an older browser landing on an http:// page sees no change.
Microsoft went on the record in the list as preferring to encourage TLS in HTTP 2.0 without making it mandatory; while the Chromium project takes the opposite view, and is planning on supporting HTTP 2.0 only over a secure channel.
The debate highlights the deep concerns those in the know – that is, those actually contributing to IETF discussions – have about the security of TLS, particularly in light of the Snowden-driven belief that man-in-the-middle attacks are widespread.
However, making TLS more secure lives off in a different working group. Clearly, if a “secure channel” implementation were mandated for HTTP 2.0, it can only use those security mechanisms that are available to it.
What might it break?
Once concern cited by the participants in the discussion is simply that a more restrictive specification would inhibit adoption of HTTP 2.0. Microsoft's Rob Trace summed it up: “we should strongly encourage the use of TLS with HTTP, but not at the expense of creating a standard that is as broadly applicable as HTTP 1.1”.
In other words, there's no point in having a “more secure” standard if it ends up being one that nobody uses.
Perhaps thornier is what the proposal would do between browser and server, in the proxies and caches that ISPs use to help manage their traffic. An ISP can only cache a popular story from The Register if the content is in the clear. Encryption makes every piece of content look like unique content.
This one's got a long way to run … ®