Re: New tunnel protocol

On 28/01/2015 4:07 p.m., Mark Nottingham wrote:
> 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 proposed a solution to that days ago. Label only what the next layer
is (TLS, or whatever) instead of next+N layer(s).

If the label is an identifiable lie (sniffing of the TLS handshake can
be done without touching anything encrypted) then correct or strip the
header.

Note how I am only speaking to verifying the Tunnel-Protocol header
itself. An act which is under the scope of this draft to make normative.
Verifying the ALPN on the TLS is left as an exercise for the endpoints
speaking TLS.


Choosing between decrypt+sniff to verify some potentially unsupported
protocol inside TLS encrypted payload, or allowing lies to affect basic
policy decisions - neither can be called desirable ways to promote use
of encryption. Quite the opposite.



> 
>> 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"
>> 
>>> 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.

Discrimination is going to happen whatever we do. I'm arguing for a
design where the discrimination *for* encryption is not tied up in knots.

An implementation which is going to discriminate against particular
encrypted protocols (h2 vs pop3s for example) currently needs to
implement decryption to do so. Lets leave it that way while making it
easy to pass-thru encrypted traffic.

Pulling the encrypted internal protocol name out into cleartext makes it
easy to discriminate against any secure protocols while letting the
insecure ones happen in a broken/decrypted way. That actively allows
hiding the interceptor for some protocols instead of making it reveal
itself.


I was planning a configuration ON/OFF knob in Squid to opaquely reject
CONNECT unless it sees Tunnel-Protocol:TLS - and only traffic that
passes that frontline gets deeper inspection at sysadmin choices of
ACLs. Its a common enough feature request.
 If we are having an unbounded assortment of names for encrypted
protocols then even that gets left to the sysadmin to configure
manually. Undoubtedly ending up with uncoordinated mashup of what
protocols people know about and what protocols work per-installation.
And then lies begin to actually matter - with the on/off the worst a lie
can do is self-DoS the lying client.

Amos

Received on Wednesday, 28 January 2015 04:01:25 UTC