Re: Moving forward on improving HTTP's security

tl;dr: Opportunistic encryption being thrown over the side.  I do not think
this reflects the consensus I heard in the room or see on the mailing list.

(Or am I missing something?)


On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <mnot@mnot.net> wrote:

> In Vancouver, we continued the discussion that we started in Berlin
> regarding the use of encryption in HTTP/2.
>
> There seems to be strong consensus to increase the use of encryption on
> the Web, but there is less agreement about how to go about this.
>
> The most relevant proposals were:
>
> A. Opportunistic encryption for http:// URIs without server
> authentication -- a.k.a. "TLS Relaxed" as per
> draft-nottingham-http2-encryption.
>
> B. Opportunistic encryption for http:// URIs with server authentication
> -- the same mechanism, but not "relaxed", along with some form of downgrade
> protection.
>
> C. 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).
>
> In subsequent discussion, there seems to be agreement that (C) is
> preferable to (B), since it is more straightforward; no new mechanism needs
> to be specified, and HSTS can be used for downgrade protection.
>
> (C) also has this advantage over (A), and furthermore provides stronger
> protection against active attacks.
>
> The strongest objections against (A) seemed to be about creating confusion
> about security and discouraging use of "full" TLS, whereas those against
> (C) were about limiting deployment of better security.
>
> Keen observers have noted that we can deploy (C) and judge adoption of the
> new protocol, later adding (A) if neccessary. The reverse is not
> necessarily true.
>
> Furthermore, in discussions with browser vendors (who have been among
> those most strongly advocating more use of encryption), there seems to be
> good support for (C), whereas there's still a fair amount of
> doubt/disagreement regarding (A).
>
> As a result, I believe the best way that we can meet the goal of
> increasing use of TLS on the Web is to encourage its use by only using
> HTTP/2.0 with https:// URIs.
>
> This can be effected without any changes to our current document; browser
> vendors are not required to implement HTTP/2.0 for http:// URIs today.
> However, we will discuss formalising this with suitable requirements to
> encourage interoperability; suggestions for text are welcome.
>
> To be clear - we will still define how to use HTTP/2.0 with http:// URIs,
> because in some use cases, an implementer may make an informed choice to
> use the protocol without encryption. However, for the common case --
> browsing the open Web -- you'll need to use https:// URIs and if you want
> to use the newest version of HTTP.
>
> This is by no means the end of our security-related work. For example:
>
> * Alternate approaches to proxy caching (such as peer-to-peer caching
> protocols) may be proposed here or elsewhere, since traditional proxy
> caching use cases will no longer be met when TLS is in wider use.
>
> * As discussed in the perpass BoF, strengthening how we use TLS (e.g., for
> Perfect Forward Security) is on the table.
>
> * A number of people expressed interest in refining and/or extending how
> proxies work in HTTP (both 1.0 and 2.0), as discussed in
> draft-nottingham-http-proxy-problem (among many other relevant drafts).
>
> Furthermore, other security-related work in the IETF (see the perpass BoF)
> and elswhere (e.g., W3C) may affect HTTP. For example, a number of people
> have pointed out how weaknesses in PKIX affect the Web.
>
> Your input, as always, is appreciated. I believe this approach is as close
> to consensus as we're going to get on this contentious subject right now.
> As HTTP/2 is deployed, we will evaluate adoption of the protocol and might
> revisit this decision if we identify ways to further improve security.
>
>
>