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. On Sat, Jun 7, 2025, at 17:04, Christian Huitema wrote: > Hello Raghu, > > I understand that logic, but what if public and backend are using split > mode? The IP addresses of public and backend are different. Using the > backend address for the connection immediately reveals that the > connection is directed to the backend server, even if the observable SNI > says "public". In the split mode scenario, the expected behavior is to > use the IP address of the public server, and let the public server relay > the connection to the backend. that implies: > > 1. Get the SVCB record for `backend.example.com`. > > 2. Get the A (or AAAA) record of `public.example.com` > > But then we cannot get the port number unless we download either the > HTTPS or the SVCB record for `public.example.com`, and to get the SVCB > we need to know the ALPN expected for `public.example.com`. But we > cannot, because the "public ALPN" is not part of the ECH configuration. > > -- Christian Huitema > > On 6/6/2025 10:25 PM, Raghu Saxena wrote: >> Dear Christian, >> >> I'm not sure on the ALPN side, but form my understanding of ECH: the >> `ech` param in the SVCB record contains the `public_name`, which is >> only used as the "Public SNI" for the initial TLS connection. In your >> example, assuming the connection was intended for >> `backend.example.com:1337` , then two DNS lookups would be involved: >> >> - 1. Get the A (or AAAA) record of `backend.example.com` >> - 2. Get the SVCB record for `backend.example.com` (with potential >> port-prefix mapping). >> >> From the `ech` param, the `public_name` will be used as the SNI when >> establishing the TLS connection to the initial intended port (on >> `backend.example.com`, i.e. 1337), and the IP address that >> `backend.example.com` resolves to. The client does not need to worry >> about `facing.example.com` other than setting the SNI extension. >> >> Regards, >> Raghu Saxena >> >> On 6/7/25 8:32 AM, Christian Huitema wrote: >>> I am implementing the ECH draft, and there is something a little >>> unclear. >>> >>> Suppose a backend server "backend.example.com" implementing the >>> application protocol "example" (i.e., not H3). Before connecting, the >>> client looks up the corresponding SVCB record, and finds an ECH >>> parameter stating that the public server is "facing.example.com". How >>> exactly is the client going to find the ALPN used to connect to >>> "facing.example.com"? What about the port number? >>> >>> Yes, the client could do a DNS lookup to find details about >>> "facing.example.com", but should that request be for the SVCB record >>> corresponding to the "example" service, or for the HTTPS record >>> corresponding to H3? >>> >>> Obviously, the practical answer is "connect to `facing.example.com` >>> port number to 443 setting the outer ALPN to H3." But is that the >>> right answer? >>> >>> -- Christian Huitema >>> >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
