On Tue, Mar 3, 2026 at 5:59 PM Nick Sullivan <[email protected]> wrote:
> Hi Ben, > > To be clear, the draft doesn't claim anonymity set improvements in the CDN > case, and I'm not convinced having traffic to the public_name is even that > helpful. Most deployments will likely pick a name that has no traffic. To > the on-path observer, the initial rollout of this feature will make it > appear that many clients couldn't access configs via DNS and fell back to > GREASE. Having more or less of this traffic to blend into is more of a > transitional deployment consideration. > > I should note that the certificate covering the public_name being > compromised does not just empower an attacker to impersonate that domain, > it also allows attackers to fully strip ECH from connections with > interception. > Just to clarify the situation here, as I found this sentence a bit confusing on first read: Suppose we have a server which has names A and B with distinct certificates. It advertises ECH with A as the public name. In this case, a compromise of the A certificate allows the attacker to (1) impersonate A and (2) strip ECH for all connections but not (3) impersonate B. I don't think your text is necessarily saying anything different here, but I thought it was worth being precise. -Ekr The key for the signed ECH configs is equally powerful, but because it > doesn't need to be used in-band in each connection, it can be kept offline > or away from the edge servers. > > Back to the main point: The benefit of random SNI is about the > enumerability of the names in the anonymity set. With a single public_name, > the observer knows exactly which name identifies ECH connections. With > random names from the pool, the observer has to determine which of > thousands/millions of names might be an ECH outer SNI, and there's no easy > way to enumerate that list. > > Your scenario (1) is relevant: DNS interference means clients fall back to > GREASE, which adds non-ECH connections as cover. But that doesn't change > the anonymity set. What changes the anonymity set is whether the observer > can enumerate the names in it. > > On key isolation and document ordering: fair point, we'll review. > > Nick > > On Tue, Mar 3, 2026 at 6:24 PM Ben Schwartz <[email protected]> wrote: > >> 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]> 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]> >> *Sent:* Monday, March 2, 2026 6:02 PM >> *To:* [email protected] <[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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
