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

[Mark Nottingham <[e-mail]>]

On 18 Dec 2013, at 6:22 am, Eliot Lear <[e-mail]> wrote:

> Bringing this back around to draft-nottingham-http2-encryption, the document poses a problematic issue around what is mandatory to implement.  Some browser developers have made it clear that they're not going to do unencrypted http2.  If reality is that HTTP2 will only be implemented by browsers via TLS, then there are exactly to paths one can follow:
> 
> 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.
> 
> Let us assume that (1) is the intended target.  In that case, we have the following options:
> 	A. Demonstrate that free certificates are generally available,
> 	B. Use unauthenticated or opportunistic encryption,
> 	C. See that DANE is delivered, or
> 	D. develop another option.
> Personally I don't believe (A) and you and I have thus far rejected (B)[*].  That leaves (C), which I personally like and you have no plan to implement, or (D).  If you would like to avoid the distraction, kindly correct my understanding?  Maybe you don't grant assumption of (1).  I don't think others do, but the charter sort of pushes that point.  Anyway, this is the reason we keep circling back to DANE, as I see it.

You don't talk about (2). What is your position on that outcome?

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." 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. Again, no one has proposed that the HTTP/2 spec say that it only works across TLS.

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.

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. 

Needless to say, discussions in Zurich should be interesting.

Cheers,


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