On 12/11/19 6:09 PM, Ben Schwartz wrote:
On Tue, Dec 10, 2019 at 2:43 PM Vladimir Olteanu
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
