Hi Ben, (and re-adding tlswg) I think we agree on the coalescing point. Within a single-operator deployment, RFC 9849 already allows maximal pooling under a single ECHConfig, and this draft does not create new coalescing opportunities.
The point of the draft is different. In base ECH, that already-coalesced deployment is still encouraged to expose a single stable visible public_name in the outer SNI, and the retry path is tied to a certificate for that same name. That gives an observer a uniquely cheap and precise classifier for "connections that may be targeting this deployment", even when the deployment itself spans a large shared edge pool. A concrete example might help. Suppose "Proxywerks" is a large fronting/CDN-style deployment serving millions of domains from one shared ECH pool. All of those domains use the same ECHConfig with public_name=" proxywerks-ech.com". The actual serving footprint is a large and changing set of shared edge addresses across multiple Proxywerks ASNs plus some BYOIP space, borrowed regional ISP IPs, and all of those IPs are also used for many unrelated origins. Under base ECH, an observer who wants to flag traffic potentially destined for anything in that pool gets a very cheap classifier: if outer SNI == "proxywerks-ech.com", flag the connection That works even though the IP footprint is broad, dynamic, and shared. So in practice the visible public_name can reveal much more precise information than the destination IP. Signed ECH does not make the deployment unobservable, and it does not let the operator pool more names than RFC 9849 already permits. What it does is remove that fixed visible classifier. After that, an observer has to fall back to broader IP/prefix heuristics or maintain a larger set of candidate visible names. The reason that matters operationally is that, once the SNI has been extracted, a single fixed literal is one exact match, while a non-fixed visible name means the observer has to maintain and search a changing set of candidates. For DPI systems, that is the same TLS parsing cost plus more match state and more update churn. The line-rate SNI inspection research shows this directly: after parsing, hostname matching is implemented with exact-match tables, and larger tables consume more scarce data-plane resources (see https://research.cec.sc.edu/files/documents/P4_TLS.pdf). By contrast, IP/prefix heuristics are easier for network hardware to implement, but much blunter. They are less precise, and on shared infrastructure they are more prone to collateral damage. For example, the Myanmar censorship measurement paper notes that blocking a single Fastly IP "may lead to the blocking of more than 10,000 websites" (see https://ramakrishnansr.com/assets/myanmar.pdf). So I would frame the value of the draft as: not more pooling, but less cheap and less precise fingerprinting of an already pooled deployment, plus cleaner key separation on the retry/update path. Nick On Tue, Mar 10, 2026 at 9:53 PM Ben Schwartz <[email protected]> wrote: > From: Nick Sullivan <[email protected]> > > > I wasn’t clear in my previous note. There is some benefit for clients who > fail to retrieve ECHConfigs, but that’s secondary. The main issue is > passive traffic analysis against a distinguished ECH deployment. In base > ECH, clients are pushed toward using a stable visible public_name in the > outer SNI, and the retry path is authenticated using a certificate valid > for that same public_name. That gives an observer an easy classifier for > “clients that may be trying to reach this service.” This draft removes that > coupling: public_name remains the authoritative name for update/validation, > but it need not be the visible outer SNI, and retry is authenticated by > ech_auth rather than a public-name certificate. So the draft is not mainly > about fallback privacy; it is about removing a fixed visible classifier > while also improving key isolation. > > ... > > The main issue is passive traffic analysis against a distinguished ECH > deployment. > > Yes, but why are there multiple distinct ECH deployments to begin with? > The obvious answer would be "don't do that". Or rather, "if you want two > names to be in the same pool, you should give them the same ECHConfig". > > > In base ECH, clients are pushed toward using a stable visible > public_name in the outer SNI, and the retry path is authenticated using a > certificate valid for that same public_name. That gives an observer an easy > classifier for “clients that may be trying to reach this service.” This > draft removes that coupling: public_name remains the authoritative name for > update/validation, but it need not be the visible outer SNI, and retry is > authenticated by ech_auth rather than a public-name certificate. So the > draft is not mainly about fallback privacy; it is about removing a fixed > visible classifier while also improving key isolation. > > Removing the public_name as a visible classifier would still leave the > server IP address as a visible classifier. The ECH design presumes that > the server IP address and the public_name reveal essentially the same > information. Why would that presumption fail in practice? Why can't the > operator easily ensure that it is true? > > I am having difficulty imagining a deployment where the operator _wants_ > to blend all the names on a server into one ECH pool, but is not able to do > so using RFC 9849. > > --Ben >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
