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

"Adrien de Croy" <> Fri, 27 March 2015 01:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 18CBD1A00FE for <>; Thu, 26 Mar 2015 18:22:15 -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 yK8bN-x2ZUxK for <>; Thu, 26 Mar 2015 18:22:13 -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 C28851A005B for <>; Thu, 26 Mar 2015 18:22:12 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YbIvb-0003LN-U1 for; Fri, 27 Mar 2015 01:19:15 +0000
Resent-Date: Fri, 27 Mar 2015 01:19:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YbIvV-0003J9-TJ for; Fri, 27 Mar 2015 01:19:09 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1YbIvT-0004dr-VX for; Fri, 27 Mar 2015 01:19:09 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.3.2 (Build 4772)) with SMTP id <>; Fri, 27 Mar 2015 14:17:35 +1300
From: Adrien de Croy <>
To: Mark Nottingham <>
Cc: Martin Thomson <>, HTTP Working Group <>
Date: Fri, 27 Mar 2015 01:17:35 +0000
Message-Id: <emfb77a216-c881-4ccc-b0ac-177521265d55@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: 1YbIvT-0004dr-VX 11f56f08a036d16ad937e822c1720bea
Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
Archived-At: <>
X-Mailing-List: <> archive/latest/29033
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Mark

thanks for explaining this position.  I guess my own reasons for my mail 
were to dispute claims that the draft did not introduce ambiguity and 
allowed full description of the protocol stack.

Whether or not there is appetite for further uses of the header at the 
current time (e.g. relating to parsing / enforcement), and whether we 
should preclude future possible uses of it by IMO getting it so badly 
wrong are 2 independent issues  and I would be interested in learning of 
proposed usage of the header in its current form by middle-box vendors.

But even aside from all that, I'm not keen on proliferation of RFCs 
which are ambiguous, as this tends to lead to interop problems.

I think it's a perfectly valid desire to wish to indicate what sort of 
thing is being tunneled for purposes of choosing service levels, however 
precluding the ability to easily verify a client assertion seems to be 

How about defining 2 headers?

Tunnel-TLS-ALPN to be used if the next layer is TLS
Tunnel-ALPN if it's not TLS

Same tokens for field values.  the name of the header clearly indicates 
it's ALPN and therefore it's obvious that ALPN tokens should be used.

Otherwise I think this draft should (instead of alluding to permitted 
use for non-TLS-tunnels) warn against using the header if there's no TLS 
layer.  I wonder if there's even a use case for non-TLS at the moment 

Otherwise there's an expectation when the words "tunnel" and "protocol" 
are used, that these should actually refer to the tunnel and the 
protocol as we understand it, and this will be a source of confusion 
since in this draft they dont really map 1:1.



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

>My understanding of our position on this is that the purpose of T-P is 
>to indicate the gross semantics of the application protocol in use 
>inside the tunnel, not to allow parsing of it.
>Specifically, the motivating use case is to indicate the use of WebRTC 
>inside a CONNECT tunnel, so that a middle box can (if it wishes) assign 
>appropriate QoS, deny service (e.g. because bandwidth is extremely 
>limited), etc.
>The discussion to date covered all of this, and the place that we 
>seemed to come to was that T-P is not necessarily for use cases that 
>require every protocol in the layering to be enumerated. We do 
>understand that some people have such use cases, but we are not 
>proposing to address them with T-P.
>I think that's where we're at with it.
>I imagine we could improve the draft to make this more clear (and 
>proposals are welcome). Addressing those other use cases isn't out of 
>the question, but my current reading of the WG is that there isn't an 
>appetite to go there.
>>  On 26 Mar 2015, at 6:36 pm, Adrien de Croy <> wrote:
>>  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 
>>  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.
>>  Regards
>>  Adrien
>>  ------ 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 been
>>>>  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 
>>>  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.
>Mark Nottingham