Hi Eric, Thanks for the thoughtful response, replies inline.
On Thu, Feb 27, 2025 at 2:26 AM Eric Rescorla <e...@rtfm.com> wrote: > Nick, > > Thanks for proposing this. This is an interesting idea, but I'm not > entirely sure it meaningfully reduces the impact of fingerprinting > in practice. Specifically, it seems mainly useful when there are > ECH and non-ECH domains on the same IP and there isn't a critical > mass of ECH. More detail below. > > > Stepping back from this specific mechanism, at a high level, there are > four main types of connections, as shown in the table below: > > Client | Server Behavior > Behavior | No ECH ECH Capable > |------------------------------------------------------ > No ECH | No ECH Extension No ECH Extension > ECH Capable | GREASE ECH Real ECH > > > Any on-path attacker can easily determine whether ECH (GREASE or Real) > is in use just by looking for the presence of the ECH extension. > However, determining GREASE from Real is more complicated and mostly > depends on looking at the public name or the config_id. As this draft > observes, this is facilitated by the fact that the public names and > config IDs for ECH capable servers are public and relatively stable. > > However, an attacker who is able to learn these stable values is > *also* able to learn the IPs for these servers, which means > that they can fairly readily learn which servers support ECH, at > least some of the time. This is obviously a bigger list than just > the stable names, but I doubt is impractically large. The point > here is that ECH Capable clients will use ECH if possible, and so > if you observe an ECH handshake to a server IP that you know does > ECH, then it's a strong indicator that it's Real ECH regardless of > the public name or config_id. > > What you're proposing is bringing IP addresses into scope for the "do not stick out" property of ECH. I claim this is out of the scope of this discussion and an entirely different problem. An adversary can filter traffic based on destination IP and can choose to block ECH-capable servers if they like, that's can't be avoided by changing the TLS layer. Preventing service discovery is not part of the privacy goals of ECH. This specification in particular is meant is to allow clients to implement strategies that make it difficult to target and fingerprint ECH connections vs non-ECH connections based on what's visible on the wire. > The major remaining source of ambiguity from the attacker's > perspective is servers which share non-ECH and ECH domains on the same > IP address. In this case, you will have some handshakes that are Real > ECH and some which are GREASE, and it might be useful to distinguish > them if the set of GREASE ECH connections is a large fraction of > the connections to the server (again, non-ECH connections can be > handled separately). Is this a common configuration? > Without revealing too much, this is absolutely a common configuration and something to be expected in the roll-out. Modern reverse proxy services do not expose IP addresses of individual servers publicly. Instead, they multiplex connections for hundreds of individual domains over shared IPs at layer 4 or below. Domains with both ECH enabled and not enabled can and will share IPs (https://research.cloudflare.com/publications/Fayed2021/). Furthermore, because this new proposal is opt-in from the server's perspective, servers who won't see the benefit of improved reachability for whatever architectural reason don't have to implement it. > Separately, I don't think it works well to let the client select any > outer SNI rather than the public name, because there is a high > probability that they will choose a domain associated with a different > IP (or rather, a different provider), which would make the real ECH > detectable again. It seems like it would work better to have the > client know which domains were valid for those IPs. I don't have a > great solution here that doesn't require publishing a huge list of > customer names, though. > This draft is agnostic on this point. It doesn't mandate that the outer SNI be associated with the server at all. If the client wants to find a list of domains that are known to be served at a given IP, there's nothing stopping them from implementing this via a list or other out-of-band method. The key point is that this draft frees the client to make its own decisions and policies around outer SNI selection strategies. For example, the following strategies would all be supported: 1) Select outer SNI from the list of domains that have been connected to over the same server IP address and have presented a valid certificate (ECH or not). This strategy could be effective against a filtering algorithm that has a database of which domains are supported by which providers and what IP ranges they own. 2) Select public_name from the ECH config, and on failure, retry with a "failsafe" hostname that is known to be reachable, even if the server is known to not to support that domain. Concretely, if the client connected to example.com, a Cloudflare customer, then "cloudflare-ech.com" would go in the outer SNI. If the connection is terminated, the client tries again with "mozilla.org" "yandex.com" or another unfiltered domain name that isn't a Cloudflare customer as the outer SNI. This strategy forces filters to apply logic about which domains are hosted where to target these connections as being ECH. 3) Pick a random non-registered domain. This strategy is subject to issues with filters that know which domains are valid or registered. The point isn't that this draft provides a solution to fingerprinting, but that it enables clients to implement creative strategies with the confidence that the server they're connecting to can handle it. Nick > > > -Ekr > > > > > > > > > On Tue, Feb 25, 2025 at 11:18 PM Nick Sullivan < > nicholas.sulli...@gmail.com> 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), >> 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). As >> discussed on the TLS WG mailing list (see >> 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. >> >> To mitigate these linkability risks, various past proposals were >> considered. One idea was to randomize or override the outer SNI rather than >> always using the provided public_name. For example, Stephen Farrell >> suggested allowing clients to use an arbitrary or blank outer SNI (for >> certain use cases like censorship circumvention). This would, in theory, >> make the outer handshake less predictable, increasing traffic diversity >> across ECH connections. However, others in the WG (e.g. Chris Wood) >> cautioned that relaxing this requirement essentially reintroduces domain >> fronting, a side-effect the group was wary of. >> >> The consensus was that fallback reliability and simplicity favored >> sticking with the public_name in SNI. See Github discussions: >> https://github.com/tlswg/draft-ietf-tls-esni/issues/396 >> <https://github.com/tlswg/draft-ietf-tls-esni/issues/396#:~:text=For%20at%20least%20command%20line,benefit%20from%20that%20option%20too> >> . >> >> Relatedly, early drafts used an 8-byte config_id, but as documented in >> discussions around 2020-2021, it was shortened to one byte to reduce its >> uniqueness and tracking potential—a change that was well received by >> privacy advocates yet noted by implementers as complicating the deployment >> complexity for multi-key scenarios, though not enough to hinder deployment. >> >> Implicit ECH Configuration, introduced in >> draft-sullivan-tls-implicit-ech-00, builds on this prior work to propose a >> mode of ECH that minimizes explicit signaling of the server’s identity. >> This draft introduces an optional “implicit” mode via a new extension in >> ECHConfigContents. When this extension is present, clients MAY choose any >> valid outer SNI and a randomized config_id instead of relying on a >> potentially globally dominant public_name. Client-facing servers, in turn, >> MUST perform uniform trial decryption to ensure that every handshake is >> processed identically, regardless of whether a valid or a phony config_id >> or outer SNI is provided. >> >> 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. >> >> Importantly, I don’t believe this approach reintroduces domain fronting. >> It’s not possible to use implicit configuration ECH to connect to one site >> on a server and then trick that server into serving HTTP responses for a >> second, different site when the TLS certificate used to establish the >> connection is not authoritative for that second site – the essential thing >> that distinguishes domain fronting from other techniques. Implicit mode >> effectively relegates the outer SNI to a mostly symbolic role for these >> connections, used solely for ensuring network reachability—similar to how >> certain legacy TLS 1.2 messages were retained in TLS 1.3 to address network >> ossification issues. >> >> This change may have fit into the main ECH draft if it had been proposed >> earlier. However, ECH has already been submitted to IESG for publication, >> so I put this together as a standalone extension. I welcome your feedback >> on this proposal as we work to reduce fingerprinting risks without >> sacrificing deployability. >> >> >> Nick >> _______________________________________________ >> 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
