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