Hi Nick, I'd go for option 1. The server is opting into this mechanism, so it seems reasonable to force it to ignore the outer SNI if ECH accepts. I agree with Stephen that we shouldn't hold up publication for this change (Option 2), however I think the extension mechanism of ECH is appropriate for this.
Chris P. On Thu, Feb 27, 2025 at 5:10 PM Nick Sullivan <nicholas.sulli...@gmail.com> wrote: > Hello TLS, > > After offline conversations about how sever-side trial decryption is > implemented, I think this implicit ECH draft can be simplified. > Furthermore, it may be possible to make a small change to draft -23 to get > most of the benefits of this draft in the main ECH document. > > Section 7.1 of draft-23 of the ECH draft describes the process for > selecting candidate ECHConfigs for an incoming ClientHello. It describes > how the config_id should be used by the servers to narrow down the list of > keys to trial decrypt against. It does not recommend or prohibit using the > outer SNI in this selection process. For a server that only supports > ECH-capable domains with a single set of configurations sharing the same > public_name, the process described in 7.1 is fine. > > However, in practice, some servers simultaneously support ECH for some > domains and GREASE ECH (aka non-ECH) connections for other domains. Doing > so will entice such servers to use the outer SNI as a first-pass filter for > selecting which connections get trial decryption and which are immediately > treated as GREASE. This logic is problematic with draft-23. > > For example, if the outer SNI of an incoming ClientHello does not contain > a public_name associated with a known ECH configuration, the server can > choose to handshake with the ClientHelloOuter without even attempting to > decrypt the ECH extension as a performance enhancement. This method limits > needed flexibility on the client. Specifically, there is no MUST that says > the outer SNI must match the public_name of the ECH configuration, and > implementing this method breaks the ability for clients to violate the > SHOULD in Section 6.1 point 5, which says the outer SNI should match the > public_name. If a client connects to a client-facing server with a "dummy" > outer SNI that doesn't match, servers implementing this shortcut will > attempt to handshake with the ClientHelloOuter using a certificate that > covers that dummy outer SNI, something the client is not prepared for. If > implemented, this pre-selection logic based on outer SNI will break > interoperability with clients that follow Section 6.1, list element 5: > > It SHOULD place the value of ECHConfig.contents.public_name in the > "server_name" extension. Clients that do not follow this step, or place a > different value in the "server_name" extension, risk breaking the retry > mechanism described in Section 6.1.6 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-23.html#rejected-ech> or > failing to interoperate with servers that require this step to be done; see > Section > 7.1 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-23.html#client-facing-server> > . > > > Note 1 on this text: Placing a different value in the outer SNI does not > have to break the retry mechanism in 6.1.6. The "retry_config" is > authenticated via the public_name (which is known to the client) *not* the > name in the outer SNI. So servers who reject ECH can send retry_configs > with a certificate covering the public_name. *But not if they implement > this shortcut logic*. > > Unless explicitly prohibited, this server logic is likely to be very > common because it can save the client-facing server from having to do an > extra public key operation when trial-decrypting ECH GREASE connections > when the dummy GREASE config_id matches a supported config_id. This > deployment reality makes this SHOULD effectively a MUST in practice. At the > least, it will effectively prohibit clients from selecting dummy outer SNI > names that overlap with the set of supported non-ECH domains by the server > (a list the client has no realistic way of knowing). > > I see two solutions to this problem. > > Option 1: > Prohibit client-facing servers from using the outer SNI until they fully > confirm that the ECH extension is invalid or GREASE. > > This has a lot of benefits: > - It removes some potential legal or policy uncertainties for servers that > implement this shortcut. I understand that shared proxy servers with > multiple customers do not want to have to explain why they used one > customer's hostname in the logic for decryption of a connection to a > different customer. This is exactly what will happen with this shortcut > logic if a client sends a dummy SNI that matches a different customer. The > server uses that other customer's private key and certificate in the > connection. This change makes the outer SNI purely vestigial and guarantees > that it will not be misused for ECH connections. > - It makes it less likely that clients disregarding the SHOULD for 6.1 > point 5 will face unexpected failures, allowing this SHOULD to be relaxed > to a MAY. It could also facilitate removing the "Once the server has chosen > the correct ECHConfig, it MAY verify that the value in the ClientHelloOuter > "server_name" extension matches the value of > ECHConfig.contents.public_name, and abort with an "illegal_parameter" alert > if these do not match." stipulation in 7.1 > - It reduces the timing side-channel that this selection introduces to > outside observers, i.e., if the server handshake takes less than 3 public > key ops to run, the observer can assume the connection was GREASE and not > legitimate ECH. This is not a silver bullet, using the config_id to > shortcut the logic for ECH GREASE connections still provides a side-channel > in some cases. > > Option 2: > Tighten up the language in -23 by restoring the SHOULD to a MUST in > Section 6.1 and document the necessary logic to support outer SNIs that > don't match the public_name in a separate document like Implicit ECH. > > Notes: > - The implicit ECH draft should probably be amended to require config_id > to not be flexible, since it's not leaking much and is useful for key > selection during rotation > - Servers that plan on using a public_name that is not uniquely carved off > for use in ECH (no implicit ECH) can't use this shortcut logic. If, for > example, Google wanted to use "google.com" as the public_name for ECH for > its suite of sites like YouTube etc., then they would still have to do > trial decryption anyway. > > Nick > > > Nick > > On Wed, Feb 26, 2025 at 3:14 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
