Hi Nick, This mostly makes sense to me.
There are some challenges in the draft in terms of how various things are defined and explained, which might be why there are so many questions. My question is: why do you think it important to have an explicit PKIX mode? That is roughly the same as what happens when the extension is not enabled. Except that it comes with the added burden of having to get a certificate with a new X.509 extension, a significant burden. Though the extension can be added to any regular Web PKI certificate without changes to the validation processes, the CA/B Forum BRs would need to be revised to allow it and CA flows modified to pass it through. All of which is work that can be avoided by choosing to pretend that you don't understand this new draft. (Why this is not an EKU would be the follow-on question.) With that in mind, the design might become considerably simpler. Not having another extension point would be a distinct feature. On Tue, Mar 3, 2026, at 10:02, Nick Sullivan wrote: > Hi all, > > We've posted draft-sullivan-tls-signed-ech-updates-01 > <https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-01.html>, > > 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/ > > 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]
