[TLS] Re: Port number and ALPN of ECH client facing servers

[Christian Huitema <[e-mail]>]

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