Re: New tunnel protocol

Hi Mark

As soon as you want to verify the client assertion, you need to do some 
parsing.

I think it's a bit short-sighted to deny the potential applications that 
could be had if we allowed verification of the assertion.  I'd go so far 
as to say without being able to be verified, the header won't really add 
any value at all.  We're talking about forward proxies here, which is a 
restricted use case.  You may as well set QOS on U-A as a T-P you can't 
easily verify.

It's one thing to deny service based on a client assertion, it's another 
thing to grant some extra access.  You can do the former without 
checking, since the client has presumably no incentive to lie in order 
to be blocked.  However customers will (rightly) want verification of 
any client assertion which elevates a client's service level.

Having the client advertise the next protocol(s) in a tunnel is 
extremely interesting.  We see unwanted protocols over CONNECT all the 
time.  Probably a significant proportion of the world's email spam is 
transported this way.  Currently, we have no way other than heuristic 
protocol divination to see what the next layer is.  We start with the 
port number, look at what messages are sent etc etc.

If we were given the client assertion as to the protocol however, we 
could still deny without verification, but if policy allows the 
protocol, we need to pass it off for verification, and in this case we 
can do that trivially easily and in a way which only breaks if the 
client is lying and where the lie results in a denial to the client.

There are also products out there that add value to TLS without 
breaching privacy, for instance by checking for well formed protocol, 
protecting against certain types of exploits, and verifying server 
certificates.

So basically being deterministic around advertising of the TLS layer 
allows a lot of added benefit for IMO trivial cost (in terms of change 
to the proposal).  Could even adopt something like

Tunnel-Protocol: TLS:http/1.1
with ALPN in the TLS layer advertising http/1.1

or

Tunnel-Protocol: TLS
and use ALPN in TLS for the next layer or not so you're not leaking the 
next layer after the next layer for whatever reason.

I really just don't want to have to sniff for TLS, or have to second 
guess every ALPN ID as to whether that means it has TLS or not, and what 
to do when the inevitable confusion arises and the client gets it wrong.

My only complaint really about the draft is the ambiguity about whether 
the next protocol is TLS or not.  Surely we can think of a way to simply 
just state whether it is or not, rather than requiring the proxy to jump 
through hoops to guess?  This is new, we have an opportunity to make it 
explicit.

For whatever purpose, whether that be higher level protocol analysis or 
TLS hardening, or something we haven't though of yet.

Adrien


------ 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 5:40:17 p.m.
Subject: Re: New tunnel protocol

>Adrien,
>
>>  On 28 Jan 2015, at 2:22 pm, Adrien de Croy <adrien@qbik.com> wrote:
>
>>  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.
>
>At the risk of repeating myself -
>
>You seem to be arguing for a use case where the application payload is 
>actually being parsed by an intermediary. That is not the a use case 
>that we've discussed supporting.
>
>Again, this is *not* a negotiation mechanism -- so what are the interop 
>problems you're concerned about?
>
>Regards,
>
>
>>  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/
>
>--
>Mark Nottingham https://www.mnot.net/
>
>

Received on Wednesday, 28 January 2015 10:04:49 UTC