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]
