Re: Moving forward on improving HTTP's security

Hi Mark,

Your proposal seems to logically follow from the exchange we had in the
plenary, that in essence this group should place a bet that the benefits
of HTTP2 would propel adoption of TLS.  Seems to me that is a good
research question where the answer would be a model of the sorts of
behaviors we can reasonably expect.

In the longer term, might we reasonably expect interoperability problems
due to incompatible national cryptographic standard mandates?  That is:
if the U.S. requires one form of encryption for a transaction and Russia
requires another, and there is no means to meet in the middle, there
will be no communication.  I don't know if this one can be mitigated,
but it should probably be studied.  Maybe the right thing is to not have
these systems communicate.  That would bound our all encompassing view
of interoperability, but maybe that's a good thing.  Balkanization,
however, is not.  Not all of these problems are this working group's, of
course.  Some cross over to layer 9.

Third, there are some who are doing object-level encryption and may not
desire transport encryption.

The WG might or might not not care about the answers to these
questions.  That is, perhaps HTTP2 is targeted to a specific
application, and we should allow for that.  But if that's the case, we
should perhaps say that.

Please don't take these questions as opposition to what you propose. 
Rather I am trying to understand the tradeoffs.

Eliot

On 11/13/13 2:01 AM, Mark Nottingham 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.
>
>
>
>

Received on Thursday, 14 November 2013 00:00:10 UTC