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