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 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. 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. It doesn't use ECH (but its > clients send an ECH GREASE extension). > Server B only serves secret.example.net. It uses ECH, with a public name > of "www.example.com". > > In "unsigned" ECH, Server B needs the www.example.com 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", and Server B cannot impersonate "www.example.com". > > Q1: Why is Server B using "www.example.com" 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". The pool of connections whose > SNI says "www.example.com", connecting to servers that don't serve " > www.example.com", would produce the same anonymity set as a distinct > public name. > > If there is any doubt about whether Server B serves www.example.com, 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]
