Re: New tunnel protocol

------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Amos Jeffries" <squid3@treenet.co.nz>; "ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 28/01/2015 4:07:03 p.m.
Subject: Re: New tunnel protocol

>Hey Adrien,
>
>
>>  On 28 Jan 2015, at 2:02 pm, Adrien de Croy <adrien@qbik.com> wrote:
>>
>>  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 was discussed a fair bit when this draft was first brought up. I 
>think everyone acknowledges the limits of this approach (and perhaps 
>the draft could do a better job in that).
>
>They *very* limited cases where this is useful is in places where the 
>UA inserts the header without any user control, e.g., a WebRTC 
>implementation, and the network wants to do best-effort to QoS or 
>reject those.
>
>By their nature, such policy mechanisms are limited. We don't yet have 
>a solution for "the label on these bits are a lie." That doesn't mean 
>that all labels are useless; just that they need to be used with that 
>limitation in mind.
I think it could fulfil these goals, and do a better job at it, if it 
were possible to verify the client assertion.  Requiring sniffing for a 
TLS client hello is not going to help interop or help authors to make 
bug-free implementations.  Even trying to sniff prior to deciding 
whether to add a TLS interpreter in the parsing stack is not 
straightforward when most people use libraries for TLS.  So people will 
have to roll their own TLS packet parsers.  That seems like a really bad 
goal.

I think we must always consider the applications we haven't thought of 
yet.  And the confusion created by adopting a radically different design 
pattern to one which is in use at all layers of our stacks.

I don't have any problem with a client wishing to advertise it is using 
a protocol as a payload within TLS, and indicating there is a TLS layer 
there.  I have a problem with the ambiguity about whether there is the 
TLS layer there or not, because this requires sniffing to resolve, and I 
believe the confusion around it will cause interop problems.

Adrien

>
>
>>  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/
>>>
>>>
>>
>
>--
>Mark Nottingham https://www.mnot.net/
>
>

Received on Wednesday, 28 January 2015 03:23:24 UTC