On 6/9/2025 12:35 AM, Martin Thomson wrote:
Hi Christian,
When it comes to ECH, the client won't know about the existence of a backend
server. The only thing that the client needs to know is the name that it is
seeking to connect to. Whether this is in split mode or not, the protocol
works the same.
As for the question about ALPN, the general view is that ALPN values from the
client are in the same bucket of things as other configuration: they aren't
based on the choice of server, but on unchanging configuration at the client.
If the client is using some new protocol, then it would advertise the same ALPN
list (including that new protocol) in every connection attempt it makes. As a
result, there's not much value in trying to hide the ALPN list. This isn't
entirely clear in RFC 9460, but you can see from the example in Section 7.1.2
how the DNS record should not change what the client offers.
The purpose of the ALPN parameter in SVCB is not so much to change what the
client offers in the ClientHello, but to allow the client to filter out service
endpoints that only speak protocols it doesn't understand.
Thanks.
I am not sure about your reasoning on ALPN. I get the argument about
consistency between client connection, which means that the ALPN list is
a property of the client, not so much the servers. On the other hand, we
see these "properties of the client" used in deep packet inspection and
other shenanigans. I believe there is at least some value into hiding
what exactly the client wants to do.
I get that ECH relies on DNS for configuration, and that the HTTPS
records act very much like the MX records, finding the appropriate
service for a domain name. That's how clients identify the "client
facing server" for a "backend server", whether for finding ECH or simply
for managing proxies and load balancing. The obvious issue, noted in the
draft, is that third parties that can monitor DNS traffic will be able
to associate the HTTPS exchange with the following connection.
The "obvious" solution is to carry the HTTPS query over encrypted DNS --
hopefully not the ISP service if the goal is to hide the SNI from ISP
monitoring. But as many have noted, if the result is that all HTTPS
queries are going through a big centralized service, that service is
going to accumulate a lot of knowledge about what's going on. Endpoints
can alleviate that somewhat by using different DNS services for the
HTTPS query and the following A/AAAA query. For example, resolve HTTPS
through an encrypted open DNS resolver, cache the results, then resolve
A/AAAA though the ISP service. The encrypted resolver will know that the
client checked the HTTPS record for "backend.example.com", but will not
know whether and when there was a connection through
"facing.example.com". I would call that tactic "split and cache".
Privacy oriented endpoint can make that one better by adding "chaff".
Instead of just looking HTTPS records for just the service that they
intend to use, they could do multiple lookup for different domain names.
The encrypted resolver will of course cache all that, but that will be
low quality information that does not actually predict which of the
services the client will access. For example, that would not be a very
good input for "more precise advertisements".
But still, one of the most effective ways to reduce the outgoing flow of
information is to do caching. The HTTPS + A/AAAA exchange produces three
pieces of information: the list of facing servers that might serve the
backend service; the ECH configuration and port number for the selected
facing server; and the current IP address of that server. These three
pieces of information have their own time to live: when the relation
between backend and facing server changes due to contracts or other
arrangements; when the ECH configuration changes due to configuration
changes or software updates on the facing server; when the IP address
changes with the connectivity of the facing server. For effective
caching, I would like to split those. That means for example refreshing
the ECH configuration if the facing server returns a "rety config"
response, or doing an HTTPS lookup for the facing server rather than the
backend server -- i.e., without making further disclosure about which
service the endpoint wants to access.
That's what caused my question about ALPN. We have a little bit of mess
here because not all facing server are expected to have an HTTPS record.
The ones that implement HTTP will, but for other servers one has to look
at SVCB records instead. And SVCB records are keyed by domain name +
scheme. The scheme depends on the application, and thus from the ALPN.
If I want to refresh the data about the client facing server, I need to
know for what scheme I am doing that.
-- Christian Huitema
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
