HTTP/2 and Pervasive Monitoring

[Mark Nottingham <[e-mail]>]

I've had a few questions off-list about our stance regarding BCP188 <http://tools.ietf.org/html/bcp188> and HTTP/2, and want to make sure that the WG position is clear going into IETF LC.

The most relevant text in 188 is:

>    It is therefore timely to revisit the security and privacy properties
>    of our standards.  The IETF will work to mitigate the technical
>    aspects of PM, just as we do for protocol vulnerabilities in general.
>    The ways in which IETF protocols mitigate PM will change over time as
>    mitigation and attack techniques evolve and so are not described
>    here.
> 
>    Those developing IETF specifications need to be able to describe how
>    they have considered PM, and, if the attack is relevant to the work
>    to be published, be able to justify related design decisions.  This
>    does not mean a new "pervasive monitoring considerations" section is
>    needed in IETF documentation.  It means that, if asked, there needs
>    to be a good answer to the question "Is pervasive monitoring relevant
>    to this work and if so, how has it been considered?"

It's safe to say that pervasive monitoring is very relevant to HTTP.

We've had an extensive discussion regarding PM, most occurring during and between the August 2013 (Berlin) and January 2014 (Zurich) meetings. 

One proposal we considered was to require the use of TLS (through https:// URIs) for HTTP/2. However, some members of the community pushed back against this, on the grounds that it would be too onerous for some uses of HTTP (not necessarily CPU; cost and administration of certificates was cited as a burden, as was the follow-on disruption to applications, since transitioning from HTTP to HTTPS often requires non-trivial content changes, due to the way that the browser security model works).

We also discussed an "Opportunistic Security" approach to using TLS for http:// URIs (but without authentication). This was a bit controversial too, as some community members felt that having another, weaker kind of security defined harms the long-term deployment of "full" TLS. 

After discussion in June 2014 (New York), however, we agreed to adopt this document as an optional extension, but only with Experimental status: <http://httpwg.github.io/http-extensions/encryption.html>. It's expected that we'll ship it shortly after HTTP/2.

I would characterise the WG a having a somewhat uneasy (but also pragmatic) consensus on this outcome. 

To date, we've had one browser implementation express an intent to requiring https:// URLs for HTTP/2, one interested in https:// as well as Opportunistic Security for http:// URLs, and one that is interested in https:// as well as cleartext http://.

Note that most of the justification for our decision not to require https:// for HTTP/2 seems to be predicated on this part of our charter <http://datatracker.ietf.org/wg/httpbis/charter/>:

"The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP[.]"

... i.e., we're not able to argue that people who can't use https:// should just stay on HTTP/1.1. This charter text was written before BCP188 (and the incidents leading up to it), but has considerable support in the WG.


This is roughly what I intend to put in the Shepherd Writeup when we take it to the IESG, as of now (IETF LC may change things, of course). Does anyone have anything to add?

Regards,

--
Mark Nottingham   https://www.mnot.net/