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

[Nick Sullivan <[e-mail]>]

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