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

Amos Jeffries <squid3@treenet.co.nz> Tue, 19 April 2016 16:36 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DA312E195 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Apr 2016 09:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level:
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5wIOl-AHL2A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Apr 2016 09:36:14 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBC812E193 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 19 Apr 2016 09:36:14 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1asYYh-00043G-LK for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Apr 2016 16:31:27 +0000
Resent-Date: Tue, 19 Apr 2016 16:31:27 +0000
Resent-Message-Id: <E1asYYh-00043G-LK@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1asYYc-00042Q-Os for ietf-http-wg@listhub.w3.org; Tue, 19 Apr 2016 16:31:22 +0000
Received: from [121.99.228.82] (helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1asYYb-00035i-1L for ietf-http-wg@w3.org; Tue, 19 Apr 2016 16:31:22 +0000
Received: from [192.168.20.251] (unknown [121.98.40.13]) by treenet.co.nz (Postfix) with ESMTP id 6A9D5E6F80 for <ietf-http-wg@w3.org>; Wed, 20 Apr 2016 04:30:48 +1200 (NZST)
To: ietf-http-wg@w3.org
References: <20160419161634.Horde.7_VYZk5McZE4CAiQrQh-uXr@webmail.michael-kaufmann.ch> <7CF7F94CB496BF4FAB1676F375F9666A2A7CBD72@bgb01xud1012> <BE75D624-3A89-463A-B860-A2E83613C199@lukasa.co.uk> <5CBBE2E0-BA35-42B6-9E19-D658753D593B@greenbytes.de> <825033AC-9E67-4B81-84E6-FC5C67112037@lukasa.co.uk>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <57165D31.5070604@treenet.co.nz>
Date: Wed, 20 Apr 2016 04:30:41 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <825033AC-9E67-4B81-84E6-FC5C67112037@lukasa.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-1.178, BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1asYYb-00035i-1L e170ef06a3744ebd0807a847db408e34
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used?
Archived-At: <http://www.w3.org/mid/57165D31.5070604@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31512
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 20/04/2016 4:07 a.m., Cory Benfield wrote:
> 
>> On 19 Apr 2016, at 17:05, Stefan Eissing
>> <stefan.eissing@greenbytes.de> wrote:
>> 
>>> 
>>> Am 19.04.2016 um 17:29 schrieb Cory Benfield
>>> <cory@lukasa.co.uk>:
>>> 
>>> 
>>>> On 19 Apr 2016, at 16:16, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
>>>> wrote:
>>>> 
>>>> Stefan and Daniel point out that the server uses the Upgrade
>>>> header to "advertise support" for h2. RFC 7230 Section 6.7 [5]
>>>> states that the server MAY send the Upgrade header. It seems to
>>>> me like Apache is technically compliant. On an https connection
>>>> this information shouldn't be used to perform an HTTP upgrade
>>>> to h2, since that is invalid (but a client issue not a server
>>>> one). On an http connection the info could be used by the
>>>> client e.g. they decide to negotiate an h2 session using ALPN.
>>> 
>>> I don’t think that’s really a good way to read this section of
>>> RFC 7230. The first sentence in this section is 'The "Upgrade"
>>> header field is intended to provide a simple mechanism for
>>> transitioning from HTTP/1.1 to some other protocol on the same
>>> connection.’. Note that phrase “on the same connection”. I’d
>>> argue, based on that, that the server-sent Upgrade header should
>>> only list protocols that the server is willing to upgrade to *on
>>> that connection*.
>> 
>> The mechanism is there and could be use. I do not know of a client
>> which can though...
>> 
>> And rfc 7540, ch. 3.2 says: "A server MUST ignore an "h2" token in
>> an Upgrade header field. Presence of a token with "h2" implies
>> HTTP/2 over TLS, which is instead negotiated as described in
>> Section 3.3."
>> 
>> Reading that, a server can never support this. So, we are in
>> violation...rebels almost…
> 
> 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.


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.

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.

If one is already using h2 it is pointless to Upgrade:h2.

Amos