Hi Raghu, Thank you for your response, my replies are inline.
On Wed, Feb 26, 2025 at 6:40 PM Raghu Saxena <poiasdpoi...@live.com> wrote: > 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. > The goal here isn't for proxy providers to avoid fingerprinting, it's to give clients strategies to improve reachability when a connection fails. The immediate example that comes to mind is that of a browser connecting to a website with ECH and a middlebox failing on the connection due to handling of the outer SNI, and the client implementing a policy to retry with a different outer SNI to establish the connection. > > > ... > > > > 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) > As an other reply noted, the ECH extension is very broadly used across many networks, and blocking it outright would cause significant outages and issues. IP address filtering is out of scope as a concern for TLS. Yes, IP addresses can be blocked, but that does not have any bearing on whether the "do not stick out" property of the TLS wire protocol is satisfied. > 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 > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
