Hiya,
I'm generally sympathetic to doing work in this space but I suspect we might need more and various advice for those who want to deploy ECH - just saying how to do trial decryption well likely won't be that useful IMO. Additional things where deployment advice may be needed may include: - which ECH suites work where (some clients do not support all combinations of kem, kdf, aead for ECH/HPKE even though they support each individual alg) - guidance on publishing >1 HTTPS RR (or to never do so) There's also the issue that Yaroslav mentioned about cases where inbound proxies process the outer_sni and then there's the possible timing signals related to ECH decryption that are mentioned below. I'm not sure some or all of that might be best documented in an RFC, but it's quite possible (and I'd be willing to help if so). However, I don't think we ought modify the ECH spec now to try fix/improve these issues as we'd be quite likely to end up wanting to change more and delay things even more. (And this spec has been sooo slow already.) Lastly, in all the above, I think we ought aim to not define any ECHConfig extension types, if possible. Cheers, S. On 28/02/2025 01:07, Nick Sullivan 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
