Hi Ben,
Thanks for the careful read.
On Problem 1: this is real, and the draft says so in the Security
Considerations ("Replay and Freshness of Signed Configurations"). A
signed config is replayable until its not_after, and only expiry
closes the window, which is why the draft recommends 24 hours and
keeping it as short as your signing cadence allows. What the attacker
gains is bounded: they must be on path, hold the compromised HPKE key,
and what they get is the inner SNI of connections they steer during
that window. Inner authentication is unaffected. The key this design
removes from the fleet, one that can authenticate as the public name,
breaks real TLS connections when it leaks. That's the trade, and we
think it's the right one.
On Problem 2: "don't lose the decryption key" and "don't lose the auth
key" aren't the same ask. Decryption keys must be available on every
server that terminates connections. The signing key never touches the
request path, so it can sit in an HSM or be fully offline with
backups, as operators already treat DNSSEC or CA signing keys. That's
also what makes total state loss recoverable: sign a fresh config with
the offline key and deliver it over an outer handshake using any
certificate at all, with a cold-storage backup key pinned in
trusted_keys for the disaster case.
On retaining a long history of ECHConfigs instead of retrying: a slow
client encrypts to an old config's public key, so the only way old
history helps is if the server can still decrypt it, meaning it holds
that config's HPKE private key. A slow client can land on any
frontend, so this isn't cold storage: every server that terminates
connections carries the full history of live decryption keys, 8760 of
them at hourly rotation over a year. That's the same widely
distributed, at-risk key material your Problem 1 starts from, kept
alive for a year instead of rotated away. Rotation is how you limit
what one compromise costs; retaining the history gives that up. And
since HPKE has no forward secrecy for the ClientHelloInner,
compromising one of those servers doesn't just expose future
connections, it retroactively exposes the inner SNI of every recorded
ClientHello across the whole window. So the fix for skew trades away
exactly the post-compromise property Problem 1 asks for. I don't think
both can be held at once.
Worth noting the mechanism is opt-in per config: the signed path
applies only when the initial ECHConfig carries ech_authinfo, and
9849's 6.1.7 applies unchanged otherwise, so operators with a
public_name cert keep that recovery path. The deployments that go
signed-only are the ones that can't get such a cert, and for them,
9849 has no recovery path today. The retry-optional flag serves an
operator who can tolerate failures due to stale configs; it's
complementary to this draft, not a substitute for it.
Best,
Nick
On Tue, Jul 7, 2026 at 1:59 PM Ben Schwartz <[email protected]> wrote:
>
> I think this version is an improvement. Thanks for the revision.
> However, I still don't think this is the right direction.
>
> Problem 1: Reduced Post-Compromise Security
>
> The draft assumes that widely distributed keys are at risk of
> compromise. It attempts to reduce the impact of that compromise by
> replacing the widely distributed "public name certificate" key with a
> closely held "retry config authentication" key. However, this
> proposal also aggravates the impact if the (widely distributed) ECH
> decryption key is compromised. If an attacker compromises one ECH
> decryption key, they can acquire a retry-signed ECHConfig for that
> key, and then use it (as MITM) to downgrade future connection attempts
> to the compromised ECHConfig via the new retry flow. This attack
> applies until the not_after expires. (The not_after is presumably
> longer than the usual ECHConfig rotation lifetime.)
>
> Problem 2: Reduced Outage Protection
>
> The original ECH retry mechanism is designed to serve two main purposes:
> 1. To ensure site recovery in the event of a state loss. If the
> operator loses its ECH private keys, it can get clients to retry with
> new ones. Even if the operator loses _all_ its private keys, it can
> regenerate a valid certificate for the public_name (after a panicked
> phone call to the CA) and clients will be able to connect again.
> 2. To tolerate version skew:
> a. from "slow" clients, who are stuck on ECHConfigs so old that
> they have been wiped from the server fleet
> b. from "slow" server machines, which have not caught up to the
> latest published ECHConfig.
>
> This proposal doesn't help with #1. It replaces "don't lose the ECH
> decryption key" with "don't lose the ECH auth key", which is not an
> improvement. In this proposal, this class of risks is effectively no
> longer mitigated.
>
> This proposal might help with #2b, but only until the not_after window
> expires. Large values of not_after exacerbate problem #1.
>
> This proposal does mitigate #2a. However, this skew can also be
> mitigated by retaining a long history of ECHConfigs. Each ECHConfig
> is ~64 bytes. If you rotate them hourly and retain a year of history,
> that's 365*24*64 bytes = ~500 KB of RAM, which I believe should be
> thoroughly tolerable.
>
> Alternative approach:
>
> I think a better direction would be a simple ECHConfig extension flag
> to advise the client that retry is optional for this ECHConfig,
> because the server operator believes that they can meet their
> reliability goals without it. This also downgrades the public_name
> rule to "SHOULD unless configured otherwise".
>
> --Ben
>
>
> --Ben
>
> On Mon, Jul 6, 2026 at 7:08 PM Nick Sullivan
> <[email protected]> wrote:
> >
> > >
> > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3UNGliM4$
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-02.txt__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3ebqClVE$
> > > Status:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3UNGliM4$
> > > HTML:
> > > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-sullivan-tls-signed-ech-updates-02.html__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3hzuVSAg$
> > > HTMLized:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-sullivan-tls-signed-ech-updates__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3ehPebfU$
> > > Diff:
> > > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-sullivan-tls-signed-ech-updates-02__;!!Bt8RZUm9aw!_2mTm_qInb3MYnMyARtWKA1sm7q-zBS01w9wvGPGOphSdMW6BXGeOBg5cGjCmYy_aHjB5W4JcZhy2Qh3kODVTAY$
> > >
> > > 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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
