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

Stefan Eissing <stefan.eissing@greenbytes.de> Wed, 20 April 2016 09:50 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 AE0FF12EC4A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Apr 2016 02:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=Q/ccdWBb; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=jcGaxNSX
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 jKzlHA78lMRj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Apr 2016 02:50:42 -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 8A6FF12E856 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Apr 2016 02:50:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1asoi1-0003Hi-K5 for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Apr 2016 09:46:09 +0000
Resent-Date: Wed, 20 Apr 2016 09:46:09 +0000
Resent-Message-Id: <E1asoi1-0003Hi-K5@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 <stefan.eissing@greenbytes.de>) id 1asohy-0003GU-Mm for ietf-http-wg@listhub.w3.org; Wed, 20 Apr 2016 09:46:06 +0000
Received: from mail.greenbytes.de ([5.10.171.186]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1asohw-0003Rr-CO for ietf-http-wg@w3.org; Wed, 20 Apr 2016 09:46:06 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id 7ED3315A0C40; Wed, 20 Apr 2016 11:45:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1461145536; bh=DhaR1n50UVq1IwT59y/naVBO9mvPhWCkftrrjq8ufl8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Q/ccdWBb2dKlHBhaQoaKQ7AP9C2X1gYnMZl50gyBNzQ1g/RzehnRxCamp7+wxUUd/ rmfUJqZeuSxIPGP7gHvwd2BMXvWFdPWYWGbmjzAUGzY2zcmLWxQaWgi5ojZVRHsTY0 bnlTy/vdMFuxmeUa/19g8tek72rQ3f3bbfxgYY1w=
Received: from [192.168.1.42] (unknown [192.168.1.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id DE1C115A0541; Wed, 20 Apr 2016 11:45:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1461145534; bh=DhaR1n50UVq1IwT59y/naVBO9mvPhWCkftrrjq8ufl8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jcGaxNSXpZP4cRrPtKANoWxOUY/6u0D9mQMVB1YQqA7hjDav57RhvJoPcCqm7XZrU Xr+zdf/flhkEJcragnSYBevNGW9MgrWU3s3Xh6pBhtUSUdgC6AGf5peVMnbNWljgZV P1AKgBQuBTnHY0JgHNYmMXeFtNbOXGy7o9VN2RhU=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CH1PR03MB1916F1E7699825ACC4D741AA876C0@CH1PR03MB1916.namprd03.prod.outlook.com>
Date: Wed, 20 Apr 2016 11:45:33 +0200
Cc: Michael Kaufmann <mail@michael-kaufmann.ch>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <91D281BC-F987-488B-AEEB-6F52EE7802AB@greenbytes.de>
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> <57165D31.5070604@treenet.co.nz> <20160419233014.Horde.pDb9tRgUZYP9jgWUZg3sUna@webmail.michael-kaufmann.ch> <CH1PR03MB1916F1E7699825ACC4D741AA876C0@CH1PR03MB1916.namprd03.prod.outlook.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=5.10.171.186; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=-1.382, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1asohw-0003Rr-CO 41284e54b0dc82e110de35881a4b21ae
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/91D281BC-F987-488B-AEEB-6F52EE7802AB@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31520
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>

If backport gets the votes, next Apache httpd release will no longer carry h2 in an Upgrade: announcement. Thanks for your time.

-Stefan

PS. Which still does not make sense to me, but seems to be what the specification says...

> 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.
>> 
>> 
>> 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.
>> 
> 
> 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. 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.
> 
> Do you agree...?
> 
> Regards,
> Michael
> 
>