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<http://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]
