Re: A proposal

On 18/11/2013, at 11:19 PM, Yoav Nir <synp71@live.com> wrote:

> On 18/11/13 1:44 PM, Mark Nottingham wrote:
>> On 18 Nov 2013, at 10:18 pm, Yoav Nir <synp71@live.com> wrote:
>> 
>>> I think HTTP is used for so many things in so many scenarios, that trying to give general guidance in the base spec is asking for trouble (example: when checking certificate revocation, you use HTTP to download either a CRL or an OCSP response. You can't use authenticated TLS there).
>> Again, we’re taking about the case of a browser on the “open” Web — the many special cases don’t apply here.
>> 
> I don't think we'll reach consensus on what is appropriate for the open web. But I think de-coupling that discussion from the base document is a win. I personally don't think that denying the benefits of HTTP/2 to websites that choose not to use encryption is justified. But browser support will be determined by market forces, unless the browser vendors would like to form a benevolent cartel forcing the correct policy on all the web.

Right. This is where we started in Berlin -- that market forces could take care of this, based upon the stated preferences of peers and a good negotiation mechanism. We went back and forth on the negotiation mechanism and got to a place where the simplest  -- using https:// + ALPN -- was most attractive to the browser implementers that care about this issue -- at least for now.

We absolutely can leave this up to the market by not saying anything in our document; I said as much last week:

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

My concern is that this path of least resistance will be poor for interop. *If* it really is as simple as "we only do this over https://" that concern may fade, but more nuance can bring deployment problems. 

For example, if browsers start trying to address the "local printers/IoT" problem by selectively dropping the requirement for https:// URIs, there's a very real chance that they'll do so in slightly different ways.

Some are also concerned that this looks too much like the "do nothing" option; personally I'm not as worried about that, because at least a large portion of the browsers (by all indications so far) *are* going to do something.

So, we could go ahead and specify:
  a) how to use HTTP/2 for http:// URIs (without TLS)
  b) how to use HTTP/2 with https:// URLs (with TLS)
  c) how to opportunistically encrypt HTTP -- both 1 and 2 -- for http:// URLs
... and let the market choose what it wants to implement.

We're already working on (a), (b) is pretty much baked, and we have made a fair amount of progress on staking out (c). 

It may be that browsers start by implementing (b), after evaluating the market (and adoption rates of the current plan), decide to implement (c). Or not. If they implement (a), we'd need to stay on top of the potential interop problems (such as that described above). In the end, they might decide that doing that is too much trouble, and leave http:// URIs on HTTP/1.1. That doesn't remove all the value from (a); it just means that it'll be relegated to non-browser uses of HTTP.

There could even be a (d), if the TLS-inside-of-HTTP2 discussion gets some running code behind it.

There's also a fair amount of follow-on work that we need to consider in any case; e.g., explicit proxies, TLS profiling / requirements, and liaison for things like security UX and TLS MITM.


> BTW: Downloading CRLs or OCSP responses to verify certificates used in HTTPS is very much part of the open web.


Depending on how you define "open web" for this discussion, yes or no; we haven't gone there yet.

Cheers,

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

Received on Tuesday, 19 November 2013 03:26:48 UTC