Since there are some concerns, maybe have it as informational for now as you already have some implementations done ?
"If an RPK signing key is compromised, the server SHOULD remove its hash from trusted_keys." Is there a reason this can't be a MUST ? Overall, I see a use-case for this draft. On Tue, 3 Mar 2026 at 03:03, Nick Sullivan <[email protected]> wrote: > > 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/ > > 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]
