On Wed, Mar 4, 2026 at 1:10 PM Ben Schwartz <[email protected]> wrote:
> > With random names from the pool, the observer has to determine which of
> thousands/millions of names might be an ECH outer SNI, and there's no easy
> way to enumerate that list.
>
> Yes, but why aren't they *all* ECH outer SNIs? Why would you ever end up
> in this situation where you have a mix of ECH and ECH-GREASE going to the
> same server? This seems like a misconfigured server that can be fixed by
> publishing more ECHConfigs.
>
In the typical case where there's no DNS interference, they would all be
ECH outer SNIs and not ECH-GREASE. If there is active subversion of DNS to
strip ECH configs, you may have a smattering of ECH-GREASE connections, but
I don't think this point is particularly useful in this analysis.
> > Your scenario (1) is relevant: DNS interference means clients fall back
> to GREASE, which adds non-ECH connections as cover. But that doesn't change
> the anonymity set. What changes the anonymity set is whether the observer
> can enumerate the names in it.
>
> I think you are referring to the anonymity set of domains ("which domains
> could this connection be accessing?"), and I was referring to the anonymity
> set of connections ("which connections could be accessing this domain?").
> Regardless, I don't know how to think about the enumeration concern without
> a more detailed threat model.
>
On the enumeration concern, let me use your two questions to lay out a more
detailed threat model. Consider a CDN with millions of domains sharing ECH
infrastructure. The "alias set" is the set of domains that share a given
ECH configuration. This data is available in DNS, but DNS queries are keyed
by domain name. There is no reverse lookup that gives you all domains
sharing a given ECH configuration. Constructing the alias set requires
scanning the DNS or CT logs namespace, or long-term data collection.
Current case (client uses public_name as outer SNI):
Q1: Which domains could this connection be accessing?
The observer sees SNI=P going to a CDN IP. The inner SNI is encrypted. The
connection could be accessing any domain that uses P as its ECH
public_name. To find those domains, the observer needs the alias set. No
shortcut.
Q2: Which connections could be accessing domain X?
The observer is interested in secretsite.com, which uses ECH with
public_name P. All ECH connections to secretsite.com use P as the outer
SNI. The observer filters for SNI=P. Done. No alias set needed.
So today, Q1 is hard but Q2 is trivial.
Random SNI case (client picks a random domain from the pool as outer SNI):
Q1: Which domains could this connection be accessing?
The observer sees SNI=randomsite.com going to a CDN IP. Same situation as
above. The connection could be accessing randomsite.com itself, or any
other domain on this infrastructure. The observer could look up
randomsite.com in DNS, find its ECH config, find the public_name. But then
they need all other domains sharing that public_name, and there's no
reverse lookup. They need the alias set.
Q2: Which connections could be accessing domain X?
The observer is interested in secretsite.com, which uses ECH with
public_name P. But the outer SNI of a connection to secretsite.com could be
any domain in the pool, not just P. The observer doesn't know which domains
are in the pool. They can't filter on a single SNI value. They need the
alias set to know which outer SNIs to look for.
Now Q1 is still hard, and Q2 is also hard.
The difference is Q2. Current ECH gives the observer a trivial filter.
Random SNI removes it.
> Is a primary motivation of this draft to improve privacy when some users
> are prevented from retrieving the ECHConfigs, by giving ECH and ECH-GREASE
> overlapping wire images? If so, the draft could make that a lot clearer.
> Then we can think through the details (Why would an attacker bother with
> this attack if they can observe and modify DNS? Can the attacker inject a
> false ECHConfig? How would the client choose the public name? Is there a
> better defense for this situation?).
>
As for whether the primary motivation is improving privacy when users can't
retrieve ECHConfigs: that's one way of describing the outcome of deploying
this. ECH and ECH-GREASE currently have an identical structural layout.
However, there is currently a distinguisher: is the outer SNI a known
public_name, or not? This draft removes that distinguisher by letting
clients use names that aren't the public_name while still supporting retry.
Your follow-up questions are worth thinking through carefully. The security
of this mechanism depends on the authenticity of the initial ECHConfig, as
the draft states in Section 7.2. A DNS-capable adversary can subvert that,
but that's true of ECH generally, not specific to this draft. The attacker
we're imagining is a network observer doing high-volume traffic analysis,
targeting particular domains by SNI and flagging client IPs. That attacker
benefits from a single known public_name because it gives them an easy
filter. Random SNI forces them to either enumerate the alias set or give up
on SNI as a signal.
> --Ben
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
