I have this difficulty to understand the whole point of this email. All of sudden, something that i used to believe become something that i need to be shut about. Nevermind that but does it even make my life easier and earning freely? I have too much of half baked interest on every i saw because of the influencers talk. Does it make sense? Let me know what you think for Youtube just in case i got interested just hiw complicated this whole thing that we curious about.
On Thu, Mar 5, 2026, 7:52 AM Nick Sullivan <[email protected]> wrote: > > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
