Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol

"Adrien de Croy" <> Thu, 26 March 2015 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 648351A1AA0 for <>; Thu, 26 Mar 2015 16:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4dSqoayHiYkl for <>; Thu, 26 Mar 2015 16:41:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 776531A1A8A for <>; Thu, 26 Mar 2015 16:41:43 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YbHLX-0007HI-UQ for; Thu, 26 Mar 2015 23:37:55 +0000
Resent-Date: Thu, 26 Mar 2015 23:37:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YbHLN-0007Fz-9G for; Thu, 26 Mar 2015 23:37:45 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1YbHLL-0002jM-Dn for; Thu, 26 Mar 2015 23:37:45 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.3.2 (Build 4772)) with SMTP id <>; Fri, 27 Mar 2015 12:36:11 +1300
From: Adrien de Croy <>
To: Martin Thomson <>
Cc: Mark Nottingham <>, HTTP Working Group <>
Date: Thu, 26 Mar 2015 23:36:11 +0000
Message-Id: <em8080aed5-6047-40b7-9cca-ac03bcb97ba0@bodybag>
In-Reply-To: <>
Reply-To: Adrien de Croy <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-1.095, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YbHLL-0002jM-Dn f320786d2df0c7edfc046079ec834ae4
Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
Archived-At: <>
X-Mailing-List: <> archive/latest/29029
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

hi Martin

I must have misread something then, because it seems to me from the 
draft that the Tunnel-Protocol header is intended to contain what either

a) could be in a TLS ALPN negotiation if the next layer is TLS (T-P 
identifies the next layer after TLS)
b) would identify the protocol directly if the next layer is not  TLS 
(T-P identifies the next layer)

and that it be the same token(s) whether or not the next layer is TLS.   
E.g. explicity NOT 2 versions of an ALPN token one of which indicates 
the presence of TLS and one not.

So I can't see how the same ALPN token can distinguish that the next 
layer is TLS or not unless it must always be TLS, in which case you're 
at pains to avoid saying so and my question would then be why?

My personal opinion is that TLS is as much a protocol as anything else 
and if the next layer in a tunnel is TLS, then it's just an error to not 
say so or to say it's something else.  It just breaks the basic layering 
that the internet is based on.

This is what Amos was referring to I believe when he suggested 
indicating TLS and then using TLS ALPN for the next layer after that.



------ Original Message ------
From: "Martin Thomson" <>
To: "Adrien de Croy" <>
Cc: "Mark Nottingham" <>; "HTTP Working Group" 
Sent: 27/03/2015 2:52:27 a.m.
Subject: Re: Working Group Last Call for 

>On 25 March 2015 at 16:12, Adrien de Croy <> wrote:
>>  The feedback from proxy vendors on this proposed header seems to have 
>>  largely ignored.
>I'm sorry if you think that is the case, because that was certainly
>not my interpretation of the discussion.
>The answer to your concern was that application tokens identify the
>entire protocol precisely. This is the decision regarding ALPN use
>that has been codified into HTTP/2.
>I understand that this made a few people sad and they wanted something
>else - primarily something that had explicit and separate
>identification for TLS - but we don't have an alternative that is
>well-enough defined to use.