Re: New tunnel protocol

Hi Martin

I think thatt's a lot clearer, however it still seems to basically be 
saying "if you see a protocol id, it may or may not be over TLS over the 

I guess you could make the argument that if a protocol is over tls, the 
protocol name should indicate that, e.g. instead of advertising smtp, 
you'd advertise smtps.

But if someone for some unfathomable reason were to try to describe 
smtps over tls, that wouldn't be possible I guess.  I think it could be 
useful to have a separate attribute clearly indicating the use of TLS or 


Tunnel-Protocol: smtp; tls-layer=on;

Otherwise TLS is kinda having some different status, when you could put 
an argument that if the next level is TLS, then T-P should only ever say 
TLS, maybe indicate next level after that some other way such as

Tunnel-Protocol: TLS; next-layer=smtp

A proxy verifying this can then know explicitly whether to expect TLS 
next, and whether the ALPN in TLS should match what is specified as next 
protocol etc.

Also the language about proxies not i mplementing the tunneled protocol 
I wonder is a bit optimistic, we see a lot of traffic / different 
protocols non-web-related going over CONNECT tunnels, and customers want 
to control them, sometimes to a degree which requires protocol 



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

>On 21 January 2015 at 14:34, Adrien de Croy <> wrote:
>>  So there's room for ambiguity around whether the next layer (after 
>>  is TLS or not. Or do we rely on the identifier also indicating it is 
>>  TLS, in which case what if there are 2 TLS layers?
>I get your point. My understanding, and what is written down, were
>indeed quite different.
>Does this help?
>(when Travis catches up)

Received on Thursday, 22 January 2015 01:56:39 UTC