Re: HTTP/2 and Pervasive Monitoring

[Amos Jeffries <[e-mail]>]

On 15/08/2014 2:58 p.m., Mark Nottingham wrote:
> 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. 

Nod.

> 
> 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.
> 

While the particular trigger incident(s) for BCP188 had not occured. I
recall that (at least some of) the WG voting on charter was aware of PM
issue itself and earlier incidents of the same nature as leading to BCP188.
I am also confident that a solutino exists. We just have to agree on
what it looks like.

Amos

> 
> 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/
> 
>