[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

[Raghu Saxena <[e-mail]>]

Hi Nick,

On 2/26/25 3:14 PM, Nick Sullivan wrote:
>
> Hi everyone,
>
>
> I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” 
> (https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html 
> <https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html>), 
> as a potential starting point for improving ECH’s “do not stick out” 
> compliance. Global deployments of ECH have become biased because a 
> single public_name dominates most ECH connections, making it a prime 
> target for fingerprinting (see 
> https://github.com/net4people/bbs/issues/417 
> <https://github.com/net4people/bbs/issues/417>). As discussed on the 
> TLS WG mailing list (see 
> https://mailarchive.ietf.org/arch/msg/tls/4rq4sZzpI9rjYgDLJ2IO-vG9DRw/ 
> <https://mailarchive.ietf.org/arch/msg/tls/4rq4sZzpI9rjYgDLJ2IO-vG9DRw/>), 
> the outer SNI remains the primary identifier that enables on-path 
> adversaries to identify ECH traffic.
>
I think the real problem here is centralization of the internet through 
certain "proxy providers" such as cloudflare, to whom websites are 
giving up their TLS control. If the goal is for cloudflare (or other 
such large operators) to avoid fingerprinting via the public_name, a 
solution could be to publish an ECHConfig with a bogus domain (e.g. 
`fake.example.com`), and expect that OuterSNI against a certain config 
id. They can then rotate to other random domains since they control the 
HTTPS DNS record anyway.

> ...
>
> This approach enables clients to adopt custom strategies for 
> maintaining broad reachability, ensuring that a single public_name 
> does not become a reliable way for external observers to distinguish 
> ECH from ECH GREASE at scale. It is also useful for improving privacy 
> when client-facing servers support only one or a small number of 
> domains, as it enables clients to choose the outer SNI such that it is 
> not merely a direct stand-in for the inner name.
>
I think in the context of the censor discussion you linked, 
realistically they can just block ECH (including GREASed ECH), since 
there isn't really mass saturation of ECH (GREASed or not) across most 
TLS clients, so they won't face much blowback, especially since it 
appears they've straight up said ECH is banned technology. In fact if 
I'm not mistaken the GFW already does this. IMO if Russia if OK to block 
the `cloudflare-ech.com` SNI right now (which would effectively block 
all Cloudflare websites from ECH-enabled clients), they're probably not 
afraid to block entire IP ranges in the foreseeable future (or 
fingerprint on the ECH extension + destination IP)

In general though, I do like the idea of "randomized" Outer-SNI to avoid 
leaking details to passive adversaries (I've written on the mailing list 
about this before a bit as well), however if the goal is nation-state 
level censorship circumvention in the context of popular CDN services, 
I'm not sure this will help too much.

Regards,

Raghu Saxena