search

martinthomson / alt-svcb

HTTP Alternative Services, Plan B
Other
0 stars 5 forks source link

SvcB-Used Signal #27

Open enygren opened 1 year ago

enygren commented 1 year ago

For use-cases where this is trying to do load balancing (a major use-case), cluster load balancers are going to need to know which SVCB record was used for a given TLS connection. Today many load balancers do this by looking at SNI, but since this doesn't change the SNI that won't be available.

The gross solution (not requiring protocol changes) would be to embed information in the ECH Key-ID (eg, having a different ECH per SVCB record), but this defeats a bunch of the benefit of ECH and leaks information to the network. Embedding information in IPv6 addresses would also work, but again leaks information to the network.

An alternative would be to have a new SvcParam for a SVCB identifier (eg, id=$token) and then to have a TLS ClientHello extension for SvcB-Used that passes along $token from the SVCB record used to make the connection. I'd propose that this SvcB-Used extension only be sent in an Inner ClientHello and only when ECH is in-use. That would both encourage ECH usage and also avoid leaking this information to the network.

A question would be what size to make $token. Given that more abusive hacks could easily already smuggle 64+ bits (through IPv6 as an example) that might be a reasonable starting point.

This does create linkability between the DNS lookup and the TLS connection, but there are other ways to do that for a malicious actor who controls both endpoints. A goal would be to make it so that the network / a third-party adversary can't do this linkability.

martinthomson commented 1 year ago

I don't think that we need to worry about the privacy problem that comes from smuggling info through a transition. If the data comes from the original connection, there are easier ways to carry state over. Generally, privacy sensitive applications would only perform Alt-Svc[B] if they were already prepared to retain state. For a browser, that boils down to partitioning any such state. Or you might think of this as resumption.

The idea is definitely worth exploring. It should be easy to do something, though for clients it might be easier at the HTTP layer (a setting, perhaps) than TLS.

MikeBishop commented 1 year ago

The issue with an HTTP setting is that it often requires completing the handshake before you receive it, while something in the TLS handshake can be read (with appropriate keys) while routing the initial packet.

martinthomson commented 1 year ago

Aside from plumbing challenges, in TLS - without ECH - we're signaling something new in the clear.