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



Attachment: OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to