[TLS] Re: New Version Notification for draft-sullivan-tls-si gned-ech-updates-02.txt

This document seems much simplified from previous versions, which is
good.

I think the section on replay attacks could use some
work. Specifically, ISTM that an attacker can replay any signed
ECHConfig within the validity window. This is particularly serious in
cases of disablement. Section 8 sort of covers this:

   This specification introduces no new privacy risks beyond those
   already present in TLS and DNS when used with ECH.  ECHConfig updates
   are delivered within encrypted TLS messages, preventing passive
   observers from learning about configuration changes.  Server-directed
   ECH disablement (a signed ech_auth with disable set to 1) could
   degrade privacy if signing keys are compromised, similarly to how a
   valid TLS certificate for the public name could be used to disable
   ECH.

Unless I misunderstand, key compromise isn't needed. Consider what
happens if the server serves [disable=1, not_after=86400] at T=0, and
then re-enables ECH at T=3600. An attacker who captures that config
(which happens if they just connect to the server and offer ECH) can
replay it to any client up to T=86400 (modulo DNS caching) thus
getting the client to disable ECH and learning the ClientHello.

Assuming I'm right, this is actually a fairly significant regression
from 9847, in which disablement wasn't replayable and so you needed
to actually compromise a key.

This seems like it's kind of inherent in this design and maybe it's
a good tradeoff, but I think at minimum you need to make it clear.

FWIW, I wouldn't put this under "privacy considerations". The
confidentiality of CH is the core point of ECH, and so I think
this is at least a security issue.

-Ekr


On Mon, Jul 6, 2026 at 4:07 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://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]
>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]