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

[Christopher Patton <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>