Re: New tunnel protocol

I tried reading it a few more times, I think my issues are round wording 

  "When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol 
header field may be used to carry the same  ..."

So there's room for ambiguity around whether the next layer (after 
CONNECT) is TLS or not.  Or do we rely on the identifier also indicating 
it is over TLS, in which case what if there are 2 TLS layers?

Also I'm having trouble with the concept of using CONNECT to establish a 
TLS tunnel.  It sounds in this case like the proxy does the TLS 
handshake and crypto, which is not what happens.  The endpoints do that. 
  Maybe better wording would be

When CONNECT is used to establish a tunnel that will be used to carry 
TLS.... or similar.



------ Original Message ------
From: "Adrien de Croy" <>
To: "Martin Thomson" <>
Cc: "Mark Nottingham" <>; "HTTP Working Group" 
Sent: 22/01/2015 11:08:43 a.m.
Subject: Re: New tunnel protocol

>so is the plan to identify the next protocol as "TLS" and use ALPN 
>within the TLS handshake to identify the next layer after that? It 
>would be great to re-use the identifiers, but it's not at all clear 
>from the draft.
>------ Original Message ------
>From: "Martin Thomson" <>
>To: "Adrien de Croy" <>
>Cc: "Mark Nottingham" <>; "HTTP Working Group" 
>Sent: 22/01/2015 11:05:44 a.m.
>Subject: Re: New tunnel protocol
>>On 21 January 2015 at 14:01, Adrien de Croy <> wrote:
>>>  one comment on this. It seems this header is intended to be used 
>>>only when
>>>  the next protocol is actually TLS, and the one after that is the one 
>>>that is
>>>  identified by this header.
>>We've used ALPN to describe non-TLS protocols already: h2c.
>>This is definitely usable outside of TLS.

Received on Wednesday, 21 January 2015 22:35:21 UTC