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

[Stephen Farrell <[e-mail]>]

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 <[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]