Thanks for the explanation! In the primary intended use case (in which the server genuinely serves the public name), the claimed benefits related to key isolation would not apply, so I found their presence confusing. I suggest moving those benefits later in the document.
We can compare the connection anonymity sets of "classic ECH" with "random SNI ECH", in which the SNI indicates a random hostname served on this pool. * Classic ECH: all ECH connections + all ECH-GREASE connections to the public_name. * Random SNI ECH: all ECH connections + all ECH-GREASE connections to any name on this pool. Random SNI only seems to be beneficial if a substantial portion of connections to the pool are sending ECH-GREASE. Is this a common situation? Why? If we presume all ECH-GREASE clients are ECH-capable, this would only occur if (1) some clients were unable to retrieve the ECHConfig (e.g. due to DNS interference) or (2) some domains in the pool do not publish ECHConfigs. (2) seems easily solved by publishing the missing ECHConfigs, leaving (1) as the most logical motivation. Am I understanding the intended use case correctly? --Ben Schwartz ________________________________ From: Nick Sullivan <[email protected]> Sent: Tuesday, March 3, 2026 5:02 PM To: Ben Schwartz <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [TLS] ECH Signed Configs -01 Hi Ben, I think your questions are really about "why does this draft exist," so let me start there before answering Q1-Q3. What this draft does: It decouples retry authentication from the public name's TLS certificate. This enables Hi Ben, I think your questions are really about "why does this draft exist," so let me start there before answering Q1-Q3. What this draft does: It decouples retry authentication from the public name's TLS certificate. This enables three things: 1. Passive anonymity set blending. In your two-server scenario, a passive observer sees SNI=www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$> going to both Server A and Server B. Without probing, they can't tell which connections are real and which are ECH. The anonymity sets bleed together across servers from a passive observer perspective. Your probing argument is correct that an attacker with probing capabilities can distinguish them, but passive DPI alone cannot. 2. Client-driven name diversity on shared infrastructure. Consider a CDN with millions of names and one or more ECH public names. A client can pick a random name from the pool as its outer SNI. The server genuinely serves that name, so probing confirms nothing. Using a different name each time prevents a passive observer from linking connections to the same backend. The ECH spec allows this, but the retry mechanism requires the server to present a valid cert for whatever name the client picked, which kills that flexibility in practice. This draft removes that constraint. 3. Key isolation. In your example, you noted that unsigned ECH requires Server B to hold a valid cert for the public name, and that same cert lets Server B impersonate www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>. This draft replaces that with a purpose-limited signing key. The PKIX method uses a certificate with a critical extension that prevents it from being used for TLS server auth. If the signing key is compromised, the attacker can forge retry configs but cannot impersonate any hostname. With that context: Q1: The two-server/two-IP scenario isn't the primary target, but it does provide passive anonymity set blending as described above. The primary target is shared infrastructure where both names terminate on the same IPs and the server genuinely serves the public name. Q2: The server sends a syntactically valid Certificate message because TLS requires it, but the client doesn't validate it when ech_auth validation succeeds. The outer handshake is just an encrypted transport for the signed retry configs. The draft is underspecified here. I've proposed a change: https://github.com/grittygrease/draft-sullivan-tls-signed-ech-updates/pull/15 Q3: The operational benefit of many different hostnames is anti-correlation: if the client uses a different outer SNI each time, a passive observer can't link connections to the same backend. Wildcards are one way to get name diversity without per-name certs, but they only help if clients pick subdomains of a single domain. Even then, the parent domain is visible in the outer SNI, so an observer immediately knows all the connections share a parent. If clients are picking arbitrary names from the CDN's pool, which is the interesting case, wildcards don't help at all. And the wildcard key is still a TLS server auth key, so the key isolation problem remains. Nick On Tue, Mar 3, 2026 at 1:26 PM Ben Schwartz <[email protected]<mailto:[email protected]>> wrote: I'm having trouble understanding the intent of this draft. I think the situation imagined here is that we have at least two Servers, A and B, with distinct public IP addresses. Server A only serves www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>. It doesn't use ECH (but its clients send an ECH GREASE extension). Server B only serves secret.example.net<https://urldefense.com/v3/__http://secret.example.net__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoyogh_B80$>. It uses ECH, with a public name of "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>". In "unsigned" ECH, Server B needs the www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$> certificate's signing key to recover from decryption failures. In this draft, Server B's recovery flow uses some other signing key that was approved in the ECHConfig. This ensures that Server A cannot learn the secret SNI "secret.example.net<https://urldefense.com/v3/__http://secret.example.net__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoyogh_B80$>", and Server B cannot impersonate "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>". Q1: Why is Server B using "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>" as the public name? In our usual threat model for ECH, we assume that the contents of the DNS (mapping hostnames to IP addresses) is public. The attacker knows that Server B does not actually serve "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>". The pool of connections whose SNI says "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>", connecting to servers that don't serve "www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>", would produce the same anonymity set as a distinct public name. If there is any doubt about whether Server B serves www.example.com<https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!6U6WyuMMQcqSwzLj18PJhpKvQkrYGuBAe6XhXm5gddHZHqxthPaYUwebKpSKO7tFE8fnHVHdU39GNBoydqKTv5w$>, the attacker can easily confirm it by probing. Even for a large CDN, performing a scan like this every few minutes would be fairly easy. Q2: What does the recovery flow response from Server B look like, apart from ECH? Does it have a certificate chain? For what name? Q3: Section 4.1 says: A server can use many different public hostnames (even per-client, per-connection unique ones) for other operational reasons [I-D.ietf-tls-esni], without having to obtain certificates for each. * What is the operation benefit of using many different hostnames? * This was already possible using wildcard certificates. What is the benefit of avoiding wildcard certificates? I wonder if this was intended to provide a privacy defense, by increasing the attacker's cost to map which servers offer which hostnames (as mentioned in Q1). But surely a stronger privacy defense would be to use a name that is definitely served on that host, providing true ambiguity. In that case, the public name certificate's signing key is available, so the basic ECH recovery flow will work fine and signed ECH is unnecessary. Thanks, Ben Schwartz ________________________________ From: Nick Sullivan <[email protected]<mailto:[email protected]>> Sent: Monday, March 2, 2026 6:02 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [TLS] ECH Signed Configs -01 Hi all, We've posted draft-sullivan-tls-signed-ech-updates-01, which defines a mechanism for authenticating ECH retry configurations independently of the server's TLS certificate for the public name. https: //datatracker. ietf. org/doc/draft-sullivan-tls-signed-ech-updates/ Hi all, We've posted draft-sullivan-tls-signed-ech-updates-01<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-01.html__;!!Bt8RZUm9aw!6DB1JCnSW3qA1SaoDcVAuTkRL7TsAgEveKLU3WHB4MEIV3vQ30EfhnXrEE_EPI1Xdw3345w2XHXdTEyiqxhSXoA$>, which defines a mechanism for authenticating ECH retry configurations independently of the server's TLS certificate for the public name. https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/__;!!Bt8RZUm9aw!6DB1JCnSW3qA1SaoDcVAuTkRL7TsAgEveKLU3WHB4MEIV3vQ30EfhnXrEE_EPI1Xdw3345w2XHXdTEyiEAw5Upg$> The core problem: when ECH fails and the server sends updated configs in EncryptedExtensions, the base ECH spec requires the server to hold a valid certificate for the public name to authenticate them. This limits which public names operators can use and ties ECH key rotation to certificate management. This draft defines two authentication methods: - RPK: The initial ECHConfig (via DNS) carries SPKI hashes of authorized signing keys. Retry configs carry a signature from one of those keys. Lightweight, no CA dependency, but requires operator key management. - PKIX: Retry configs carry a certificate chain with a new critical X.509 extension (id-pe-echConfigSigning) that authorizes ECH config signing for the names in the SAN. The critical bit prevents the certificate from being accepted for normal TLS authentication. Both methods use a not_after timestamp to bound the replay window for pre-signed configs. The ECHConfigTBS is constructed by zeroization. The draft splits authentication policy (ech_authinfo, carried in DNS) from the signed authenticator (ech_auth, carried in TLS), so DNS records stay compact and the signing material is only present where it's needed. We also have an early interop repo with implementations in Rust, Go, and NSS (C), all cross-verified: https://github.com/grittygrease/ech-auth-interop We'd welcome review from anyone interested, particularly on: - The wire format and TBS construction - The PKIX critical extension approach - Deployment considerations for key rotation Nick (with Dennis Jackson, Alessandro Ghedini)
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
