Re: New Version Notification for draft-nottingham-http2-encryption-02.txt

Hi Mark,

On 12/18/13 8:00 AM, Mark Nottingham wrote:

> 1.  Everyone can and will use TLS in all circumstances; or
> 2.  Not everyone can and will use TLS in all circumstances, and hence HTTP2 is not a replacement for HTTP.
>
> [...]
> You don't talk about (2). What is your position on that outcome?

Since you asked...

>
> Our charter says:
>
>> The resulting specification(s) are expected to meet these goals for common
>> existing deployments of HTTP; in particular, Web browsing (desktop and
>> mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and
>> intermediation (by proxies, corporate firewalls, "reverse" proxies and Content
>> Delivery Networks).
> Note "specifications." 

Well, no: "specification(s)".  The WG should conscientiously decide this
at some point.  We have many examples going in either direction.  But it
seems premature to discuss the matter now.

> I.e., we're not required to make HTTP/2 a replacement for HTTP/1 *in the market*, as such; only to make the specs suitable for it. 

To answer your other question and the charter, since you went there, I
don't really see a net benefit for most non-browser uses.  We've limited
participation from non-browser people in this working group.  The
charter says a bunch of other things as well that will probably cause
problems down the line, if not addressed.  But sometimes that means the
community should change or ignore the charter and not the spec.  Quite
frankly we're not there yet and there's good work being done.  Let's not
lose that fact.

> Again, no one has proposed that the HTTP/2 spec say that it only works across TLS.

And now let us add up the previous email with my statement above.  A
lack of interest from non-browsers and a statement from most browser
people that they aren't going to implement HTTP/2 upgrade means that it
will only work over TLS.  Ok... so then let's come back to path (1) and
sort the issues associated with it.
>
> In fact, it goes on to explicitly place "Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers)" as out of scope, meaning that, technically, *all* of this discussion is off-topic, since we're not (as per our charter) going to specify what Web browsers do per se; we're just defining the protocol on the wire. Nothing in 2616 prevents a Web browser from deciding to only support https://, for example, and -- so far -- HTTP/2 is just as neutral as /1.

Keep in mind the Tao: rough consensus and running code.  Think about the
shepherd write-up that must be done.  Whatever the charter says, we're
discussing running code at this point.  It's the generality of the spec
that's in question, but see above.  That doesn't necessarily mean change
the spec.

>
> Now, I suspect that we may decide that we *want* to specify (or at least document) browser behaviour regarding HTTP/2 to improve interop in that use case; if so, we'll need to get the charter changed. However, I'm not at all inclined to use such a change to force browsers to behave against their will, or to use it as "leverage" against them, since they're heavily invested in this process already based upon the current charter. 

Since none of us are kings or deities nobody will be forcing anyone to
do anything.  The issue I was addressing was really that DANE is
something that can facilitate deployment of the specification, and that
it is directly relevant to the previous discussion.  Especially if you
want to get to TLS.  Which brings up Martin's email:


> I'll make my point again.  Zero dollars (or your currency of choice)
> is not the same as zero friction.  It's an important part, but as long
> as it requires anything other than zero effort, free is still
> insufficient to move the needle in any meaningful way.

I couldn't agree more, and I've said as much.  One of the reasons DANE
is very attractive is that it addresses not only the cost of the certs
but also the friction you mention.  It's a whole lot easier for a
developer to consider a platform in which certificates are entirely
registered through the local DNS.

Eliot

Received on Wednesday, 18 December 2013 08:01:03 UTC