Re: Moving forward on improving HTTP's security

Hi Eliot,

On 14 Nov 2013, at 7:59 am, Eliot Lear <lear@cisco.com> wrote:

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

Yes, as much as any such model can be accurate. The second-order and following effects are the hard part.

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

Yep, this has come up a few times. Stephen is still working on characterising the outcome of the PERPASS BoF, AIUI, but there was discussion there of profiling / recommending best practice for TLS, and this would fall into that discussion. Don�t know where that�ll happen yet.

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

Personally, I�m very interested in these approaches, and may be experimenting with them to see where it gets us. Whether that�s an alternate to the current approach or the spiritual successor to shttp:// URIs is anybody�s guess at the moment. Hopefully running code will help illuminate that discussion.

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

Not at all; we all are. The point I want to re-emphasise to everyone is that the intent is to build on that approach, as well as constantly evaluate it. 

Cheers,

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

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

Received on Thursday, 14 November 2013 01:34:38 UTC