This looks like a reasonable change. I hope that this moves forward.
On Wed, 26 Feb 2025 at 11:17, 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. > > > 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
