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.
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?
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.
-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
