Re: Richard Barnes' Discuss on draft-ietf-httpbis-http2-16: (with DISCUSS and COMMENT)

Hi Richard,

On 23 Jan 2015, at 12:54 am, Richard Barnes <rlb@ipv.sx> wrote:

>> > (1) Section 3.2: "A server MUST ignore a "h2" token in an Upgrade header
>> > field."
>> > What is the reasoning behind this exclusion?  This seems to unnecessarily
>> > rule out the use of TLS, especially given that the server can opt out by
>> > choosing "h2c".
>> 
>> We chose ALPN as the interoperable way to upgrade a TLS connection to h2; doing Upgrade inside TLS makes no sense, because ALPN support is required, and is much more efficient (since the entire connection has to stop for the Upgrade dance). I.e., Upgrade is designed for plaintext HTTP only, and use elsewhere is a good sign that there's a buggy client.
> 
> Different problem.  You're talking about how you upgrade a TLS connection once you're making one.  I'm talking about what you do when you start with an "http" URI.
> 
> The path I'm asking about is roughly as follows:
> 1. Client: Upgrade: h2, h2c
> 2. Server: Upgrade: TLS/1.2, h2
> 3. Client: ClientHello with ALPN, ...
> 
> (Maybe include a client preamble to help with middleboxes.) It seems like that provides a path to get from an "http" URI to TLS, which is possible in h2 by virtue of the :scheme pseudo-header.  You can get to "http" over TLS via connection reuse; why would you forbid going there directly?

This implies support for RFC2817, which is pretty much unused. We haven't had any implementers express interest in that upgrade path, IIRC, and we'd need to assess it for security properties.

OTOH it's currently perfectly possible to do the following without changing the h2 spec:

1. Client: Upgrade: TLS/1.2
2. Server: Upgrade: TLS/1.2
3. Client: ClientHello with ALPN

What's the qualitative difference? 

It's true that if the server doesn't support h2, the client won't be able to multiplex http:// and https:// URLs over it, but that's going to be the case no matter what we do here. While some implementations might want to know whether their peer supports h2 before negotiating TLS, I'm not sure enabling that is a good outcome -- after all, the IAB wants to encourage use of encryption...


> One of my favorite things about this spec is that it disentangles the concepts of transport and scheme.  The two places I've called out in this DISCUSS (here and below) are the only ones where there still seems to be confusion, so it seems worth ironing them out so that the separation can be clean.

I understand, but we've prioritised interoperability and security here.


>> > (3) Section 9.1.1: "For "http" resources..."
>> > This seems to imply that requests for "http" resources can only be
>> > carried over bare TCP, which seems wrong given the presence of the
>> > ":scheme" pseudo-header.  Proposed text:
>> >
>> > OLD: "For "http" resources, this depends on the host having resolved to
>> > the same IP address."
>> > NEW: "For TCP connections without TLS, this depends on the host having
>> > resolved to the same IP address."
>> 
>> Within the scope of this specification, I think the current text is correct; further specifications (including HTTP OppSec, if it wants to) can modify this behaviour when they're in effect.
> 
> I actually think that this spec does a pretty good job of separating "cleartext/TLS" from "http/https".  The only points of confusion are here and the point mentioned above.  Regardless of whether we do OppSec, it seems worth being clear about this distinction.

Your proposed language creates ambiguity; whereas before we divided the world into http and https resources, now there would be several states.

Cheers,

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

Received on Wednesday, 28 January 2015 00:36:33 UTC