________________________________ From: Christian Huitema <huit...@huitema.net> Sent: Monday, June 9, 2025 1:13 PM
... > On 6/9/2025 12:35 AM, Martin Thomson wrote: ... >> 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. > I am not sure about your reasoning on ALPN. Martin is correct regarding the significance of RFC 9460's "alpn" parameter. ... > I believe there is at least some value into hiding > what exactly the client wants to do. draft-ietf-tls-esni Section 10.5 agrees: "A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter.". ... > 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. FWIW, these can normally be split into a CNAME or AliasMode record (www.origin.example CNAME cdn.example), a ServiceMode record (cdn.example HTTPS 1 . ech=...), and IP addresses (cdn.example. AAAA ...). This works under certain limitations: 1. The origin chooses a single split-mode service. 2. The split-mode service's backend targets are all willing to use the same SVCB parameters. 3. The domain is not an "apex" (so it can use CNAME) or the client supports AliasMode (sadly still missing in Chromium). Given that there is zero deployment (or even implementation?) of split mode today, I think it's a bad idea to add even more complexity in pursuit of incremental privacy improvements. > 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. This is essentially incorrect. Any split-mode server that wants to support AliasMode for HTTP would publish an HTTPS record, even if it does not actually accept HTTP requests for this hostname. HTTPS records cannot alias to SVCB records. > And SVCB records are keyed by domain name + > scheme. The scheme depends on the application, and thus from the ALPN. This is also sort of incorrect. The SVCB records for _foo1.origin.example and _foo2.origin.example could both be aliased to the same SVCB record on "cdn.example" ... on the condition that foo1:// and foo2:// can use the same SVCB contents. --Ben
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
