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]

Reply via email to