Re: New tunnel protocol

Hi Mark

what sort of policy is it envisioned that this protocol would enable?  
If a resource allocation policy then it would be prudent surely to not 
set up a system that people can game by lying?

That then requires a proxy to verify the client assertion if it is to 
make any use of the header at all.  So why not design a protocol that 
allows that, instead of one which abuses:

a) the excellent design pattern of a layer in a stack identifying the 
next layer
b) the ALPN identifiers

and introduces ambiguity which requires traffic sniffing and heuristics 
to resolve.  I'm pretty sure i recall several discussions about sniffing 
in various contexts on this list and it seems like a bad goal.

It seems a little ironic to me that all the people raising concerns 
about this proposal are proxy vendors, who are surely the target 
audience for this draft, and it seems foolhardy to steadfastly ignore us 
yet expect this to gain some traction in proxies.

Train wreck by committee.

Adrien



------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 28/01/2015 3:35:48 p.m.
Subject: 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 03:03:40 UTC