Dear TLSWG, We've published draft-sullivan-tls-signed-ech-updates-02, which incorporates the changes discussed at the last meeting. This version drops the PKIX dependency entirely, and retry configs are now authenticated with bare signing keys rather than a certificate chain: the initial ECHConfig pins its trusted keys as SHA-256(SPKI) hashes in a new ech_authinfo extension, each signed retry config carries its signing key and signature in ech_auth, and clients verify against the pinned set. The server's outer certificate no longer needs to be valid for the public name, and operators can rotate ECH keys without touching certificate issuance.
We also worked through what a detached signed object actually means. A signed config is replayable by anyone until its not_after time, including in the disable case, and the Security Considerations now say so directly. The IANA Considerations were corrected after IANA review. https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/ Best, Nick (for Dennis and Alessandro) On Mon, Jul 6, 2026 at 6:52 PM <[email protected]> wrote: > > A new version of Internet-Draft draft-sullivan-tls-signed-ech-updates-02.txt > has been successfully submitted by Nick Sullivan and posted to the > IETF repository. > > Name: draft-sullivan-tls-signed-ech-updates > Revision: 02 > Title: Authenticated ECH Config Distribution and Rotation > Date: 2026-07-06 > Group: Individual Submission > Pages: 19 > URL: > https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-02.txt > Status: > https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/ > HTML: > https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-02.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-sullivan-tls-signed-ech-updates > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-sullivan-tls-signed-ech-updates-02 > > Abstract: > > Encrypted ClientHello (ECH) requires clients to have the server's ECH > configuration before connecting. Currently, when ECH fails, servers > can send updated configurations but clients cannot authenticate them > unless the server has a valid certificate for the public name, > limiting deployment flexibility. > > This document specifies a new mechanism for authenticating ECH > configurations. Servers include additional information in their > initial ECH configurations, which enables clients to authenticate > updated configurations without relying on a valid certificate for the > public name. > > > > The IETF Secretariat > > _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
