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