Re: [Int-area] SOCKS6 and UDP

[Vladimir Olteanu <[e-mail]>]

On 12/11/19 6:09 PM, Ben Schwartz wrote:
>
>
> On Tue, Dec 10, 2019 at 2:43 PM Vladimir Olteanu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> >
> > Hi Ben,
> >
> > I've added my comments inline.
> >
> > On 12/10/19 7:12 PM, Ben Schwartz wrote:
> > > I have a few notes on the SOCKS 6 draft, related to UDP.
> > >
> > > 1. I would like to require servers to share resumption between TLS and
> > > DTLS.  This would allow clients to keep a single resumption cache,
> > > instead of two.
> >
> > This is the first time I hear about TLS and DTLS sharing sessions.
> >
> > It is a nice performance improvement that, as far as I can tell, doesn't
> > have any drawbacks. However, I wouldn't require it (as in MUST, REQUIRE
> > or SHOULD) since it puts extra burden on the implementers.
>
> The problem is, if it isn't required for the server, then the client 
> always has to keep separate session caches, because it has no way to 
> know if resumption tickets/keys could be shared.

The client can always probe whether or not sessions can cross over from 
TLS to DTLS. This has a one-time cost of 1 RTT.

>
> > All that
> > should be required is a functional TLS layer. (Session resumption might
> > not be supported by the library, it becomes complicated if you're using
> > an L4 load-balancer etc. etc.)
>
> True, if the TLS termination is implemented separately from the SOCKS 
> server then this could be hard to achieve.  Port 1080 is reserved for 
> SOCKS on both TCP and UDP, so maybe this requirement could apply only 
> when using TLS and DTLS on the same host and port.
>
It could be that TLS and DTLS are terminated by separate processes, or 
even separate machines, hence my apprehension about requiring this feature.

On the other hand, we can require (as in SHOULD) the client to try to 
reuse the session.

> > > Putting a very large Association ID at the beginning of every packet
> > > is not appealing, but with DTLS there may be a more secure and more
> > > efficient solution.  For example, the client could include a longer
> > > Association ID only until it gets an acknowledgement from the server,
> > > at which point both sides know that the UDP association is mapped to
> > > this DTLS connection.  Alternatively, the client could send some
> > > information about its DTLS ClientHello in the TLS channel that sent
> > > the UDP ASSOCIATE, creating a secure binding.
> >
> > Unfortunately, we can't ditch the Association ID entirely, because
> > multiple UDP associations can be multiplexed over the same DTLS 
> connection.
> >
> > Your idea about having two different Association IDs is interesting. In
> > essence, one would be "signed", and the other "unsigned". The only issue
> > is that the ID eats into the maximum payload size, and clients would see
> > the equivalent of a varying MTU.
>
> Yeah, this is inconvenient.  One can imagine a new message type like 
> "ACCEPT ASSOCIATION" that is sent on the DTLS connection, which 
> includes both a long (e.g. 128-bit) server-selected Association ID and 
> a short (e.g. 16-bit) client-selected key that identifies the 
> association on this DTLS connection (or 5-tuple).  However, I'm not 
> sure how to do this without adding a roundtrip.
>
Yes, adding round trips is something we are trying to avoid.
> > Your second idea with the ClientHello seems promissing. We could include
> > the session ID, connection ID or ticket in the SOCKS Request. (I'm not
> > sure what to do if the DTLS connection has neither.)
>
> It could just be the whole DTLS ClientHello, or a hash of it.
>
Having the proxy remember the whole ClientHello for every connection is 
costly. Hashes are doable, but it likely requires digging into the guts 
of whatever TLS library the endpoints are using.

Further, if there's a DTLS-terminating proxy, things get really messy. 
I'd hate to see SOCKS ALGs popping up.

Come to think of it, I'd say that we shouldn't rely on any cross-layer 
information for security, or for any other critical features.

Vlad