Hi Martin, This is a reasonable question. I’m definitely open to reducing this spec down to one configuration. The recent changes to remove the signature from the DNS version of the ECH config make it clear that trust is being bootstrapped from the original configuration, wherever you get it from.
Operational factors aside, the differences between the two modes comes down to what type of trust anchor for future updates you want to advertise in the initial ECH config: a public key, or a DNS name. The first is tied to the lifetime of a specific key held by the server, the second is tied to the server’s ability to issue a certificate for a given domain name. Both seem like a feasible basis for trusting updates. PKIX adds an additional layer of indirection, which could provide a bit of flexibility, but as you note, it’s at the cost of adding a burden to the PKI (new critical extension or critical EKU). I’d be interested in hearing from implementers of both the client and server what they find more ergonomic. I’d also like to know whether the flexibility of having multiple valid update keys via multiple update certificates brings any operational benefits for servers for avoiding downtime, recovering from key compromise, etc. The update key compromise recoverability story is (I think) distinctly better in the PKIX case when revocation mechanisms are in place. Whether that outweighs the downsides of involving CAs, I’m open to arguments each way. Best, Nick On Wed, Mar 11, 2026 at 3:36 PM Martin Thomson <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
