Re: Is the response header "Upgrade: h2" allowed when TLS is used?

> On Apr 21, 2016, at 3:50 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 21/04/2016 6:54 a.m., Roy T. Fielding wrote:
>>>> Am 19.04.2016 um 23:47 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
>>>> 
>>>> That would seem reasonable.  Hypothetically, a server could attempt RFC 2817-style Upgrade to TLS and then select "h2" as the ALPN token during the TLS handshake.  A logical flow for carrying the initial request into the h2 context would look a lot like that for h2c -- stream 1 is half-closed and already "contains" the client's initial request.  However, that still wouldn't use an "h2" Upgrade token and isn't actually defined anywhere.
>>>> 
>>>> "Upgrade: h2c" or offer Alt-Svc if you want to switch to HTTP/2 on a different, encrypted connection.
>>>> 
>>>> -----Original Message-----
>>>> From: Michael Kaufmann [mailto:mail@michael-kaufmann.ch] 
>>>> Sent: Tuesday, April 19, 2016 2:30 PM
>>>> To: ietf-http-wg@w3.org
>>>> Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used?
>>>> 
>>>> Zitat von Amos Jeffries <squid3@treenet.co.nz>:
>>>> 
>>>>> On 20/04/2016 4:07 a.m., Cory Benfield wrote:
>>>>>> 
>>>>>> Heh, I missed that. With that note, then, I’d say that Apache should 
>>>>>> stop putting h2 in the Upgrade header on a TLS-using connection
>>>>>> *unless* it believes that connection is for a HTTP-schemed URL, when 
>>>>>> it should put h2c.
>>>>>> 
>>>>>> Cory
>>>>>> 
>>>>> 
>>>>> 
>>>>> I think you are all overlooking the basic details:
>>>>> 
>>>>> * RFC 7540 does not govern HTTP/1.1 connections, even TLS ones.
>>>>> 
>>>>> * RFC 7540 section 3.2 is about negotiating http:// URLs over non-TLS 
>>>>> connections.
>>>>> 
>>>>> 
>>>>> When the client has negotiated for HTTP/1.1 over TLS to happen (aka 
>>>>> HTTPS). It is appropriate to Upgrade:h2. Since RFC 723x applies.
>> 
>> It can be interpreted that way, yes.
>> 
>>>>> But when the client negotiates h2c to happen. It is forbidden from 
>>>>> using
>>>>> Upgrade:h2 to get to h2. Avoiding the issues Upgrade would have with 
>>>>> only one-way encryption for the message pair.
>> 
>> Well, no, h2 as a token presumes a completely secured TLS connection.  How you get
>> there is left up to the client and server to negotiate.
>> 
> 
> No right back. It is actively forbidden with a MUST ignore.
> 
> RFC 7540 section 3.1:
> "
>   A server MUST ignore an "h2" token in an Upgrade header field.
> "
> 
> The loophole for 1.1 case is that RFC7230 is applicable. In this case
> where RFC 7540 is applicable that MUST ignore comes into play and comes
> down hard.

No, we are talking about use of h2 in responses.  3.1 only applies to requests.

>>>>> Note that h2c is also forbidden from being used in ALPN by section 3.3.
>>>>> So there is no valid way to be using TLS for h2c in the first place.
>> 
>> No, there is just no way defined by RFC7540. That doesn't mean it can't be implemented.
>> TLS is just a connection.
> 
> It is actively forbidden with a MUST NOT. Which is very different from
> "no way defined".
> 
> RFC 7540 section 3.3:
> "
>   ... The "h2c"
>   protocol identifier MUST NOT be sent by a client or selected by a
>   server; the "h2c" protocol identifier describes a protocol that does
>   not use TLS.
> "

Again, applies only to requests, not responses.

>>>>> If one is already using h2 it is pointless to Upgrade:h2.
>>>>> 
>>>> 
>>>> I have just realized that RFC 7540 registers the "h2c" upgrade token (section 11.8) but it does NOT register an "h2" upgrade token. (it also registers the identification strings "h2" and "h2c" for ALPN in section 11.1, but that is a different thing)
>>>> 
>>>> The upgrade token "h2" probably does not exist according to the RFCs.  
>>>> It is also not mentioned here:  
>>>> http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml
>>>> 
>>>> So when using TLS, servers should not send "Upgrade: h2" because "h2"  
>>>> is an undefined upgrade token.
>> 
>> No, that presumes only registered tokens can be used.  HTTP/1.1 is not so limited.
> 
> Exactly my point in that earlier mail.
> 
>> 
>>>> And also when using TLS, servers should not send "Upgrade: h2c" because h2c means "HTTP/2 using cleartext TCP", and a connection that uses TLS cannot be "upgraded" to a connection that does not use TLS.
>> 
>> No, because TLS is just a connection.  For example, it might be opportunistic TLS.
>> Or it might be a configured tunnel over TLS or SSH of which the HTTP level is unaware.
> 
> RFC 7540 section 3.3 contradicts you. see above for the applicable quote.
> 
> Once you have h2 active you are forbidden from opportunistic downgrade
> to the nsecure version of HTTP/2. Even using a secondary TLS layer with
> h2c ALPN.
> 
> You can move to HTTP/1, HTTP/3, or non-HTTP. But not to h2c.

Not relevant to this discussion.

>> It is better to think of the tokens as a protocol of their own, rather than a reference
>> to a specific protocol with the same name (or not, in the case of h2).  In other words,
>> the "h2c" token has a defined way of being interpreted that might result in some set of
>> actions by the recipient to reach some other state.  Likewise for h2, even though its
>> interpretation has not been defined by the registry.
> 
> 
> RFC 723x and prior describe things that are allowed and leave the rest
> undefined. RFC 7540 breaks that pattern and actively prohibits things -
> namely h2c in TLS and h2 outside it.
> 
> That makes it rather important to be aware of which RFC a previous
> Upgrade or ALPN (if any) negotiated to be applicable. Because being
> within 7540 scope limits what edge cases can be using for subsequent
> sub-levels of transport.

No, that is completely irrelevant.  Upgrade is defined by HTTP/1.1.  Whatever
semantics are implied by h2c are defined by RFC7540 to the extent that it does
not contradict HTTP/1.1.  ALPN doesn't even apply -- only its namespace is being
foolishly reused here.  h2 is not defined as an Upgrade token, but its implications
as a protocol are pretty clearly defined by RFC7540 except for the bits that are
TLS-specific and limited to the browser paradigm.

If you look at the semantics, HTTP/2 over an opportunistic TLS connection is h2c,
not h2.  The connection just has another layer of special sauce.  HTTP/2 over a
properly negotiated and secured TLS connection is h2, even if an h2 client is
forbidden to requesting it in Upgrade.

The fact of the matter is that HTTP (both 1.1 and 2) can be used over any connection
regardless of how many layers of security are applied under that connection.
We can't make categorical statements about what h2 runs over.  RFC7540 doesn't
(or if it does, that's an errata), but what it does do is limit what kind of
upgrades an h2 client can request. This does not limit a server.

>> BTW, if you send "Upgrade: HTTP/2.0, TLS", its interpretation is defined by RFC7230.
> 
> What RFC defines HTTP/2.0 ?

http://tools.ietf.org/html/rfc7230#section-6.7

   This specification only defines the protocol name "HTTP" for use by
   the family of Hypertext Transfer Protocols, as defined by the HTTP
   version rules of Section 2.6 and future updates to this
   specification.  Additional tokens ought to be registered with IANA
   using the registration procedure defined in Section 8.6.

> RFC 7540 does not. It is clear on that.
> 
> At best you end up with TLS negotiated, which bring in the ALPN choice
> between 'h2', 'http/1.1' or non-HTTP. Still not having reached h2c over TLS.
> 
> 
> IIRC we had these arguments already when a group of us tried to prevent
> the h2/h2c split. And still we are where we are.

It was never in scope for this working group.  These decisions were discussed in 1992,
implemented in 1993, reaffirmed in 1995-97 as RFCs, and have not been changed since.
For the same reason, what we call HTTP/2 is actually "HTTP/2.0" as far as HTTP/1.x is
concerned, regardless of anyone's opinions about the value of minor versions.
We can't adopt a legacy protocol's name and ignore the implications of its forward
versioning requirements.

....Roy

Received on Thursday, 21 April 2016 17:35:39 UTC