Re: New tunnel protocol

Hi Amos et al,

Personally, I generally agree much of your concern here -- the ad hoc way in which ALPN identifiers sprung up always made me nervous (and I've expressed that a few times). It would be nicer if there were (dare I say it) a more well-defined architecture around ALPN-as-protocol-identifier.

HOWEVER, in this case we're not talking about a negotiation mechanism, nor are we trying to allow intermediaries to parse the contents of the connection. Rather, the purpose of tunnel-protocol is a hint as to the semantics of the application inside the tunnel, so as to enable application of policy.

E.g., if the content is WebRTC, the network might want to apply different QoS, or refuse the tunnel because they're extremely bandwidth-constrained.

For those use cases, it makes no difference (that I can see) as to whether the content is encrypted or not.

What you seem to be asking for is to know whether encryption is going to be used in a tunnel up-front when you see a connection. In the current environment, designing this to allow intermediaries to discriminate against encrypted connections would be unlikely to gain traction, I think.

Cheers,


> On 28 Jan 2015, at 10:49 am, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 28/01/2015 9:42 a.m., Martin Thomson wrote:
>> On 27 January 2015 at 11:56, Adrien de Croy wrote:
>>> therein the problem.  Surely if the next protocol after TLS is smtp, then
>>> you don't advertise smtps in the TLS ALPN????
>> 
>> Why?  It's not like the TLS magically disappears even if you can decrypt it.
>> 
>>> Pretty sure captures I've seen
>>> seen for https, only advertise http inside the ALPN field in the TLS client
>>> hello message.
>> 
>> The string "http/1.1" means HTTP/1.1 over TLS.
>> 
> 
> ... and the ALPN string that means HTTP/1.1 over TCP is also "http/1.1".
> 
> I need to separately identify these two for a real-world case without
> reading any bytes following the CONNECT message. How?
> 
> 
> What I understand is that every other protocol *except* HTTP/2 uses its
> plain-text protocol label to signal "next protocol" in places like ALPN.
> So there is no way for any of those protocols to signal the existence of
> TLS using their regular label.
> 
> Amos
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 28 January 2015 02:36:24 UTC