You’re technically correct, but if you look at how TLS stacks work in practice, the amount of state they keep across connections is tiny, basically just what is needed to support resumption, if that. So tracking which public keys have been seen would be a big lift.
On the other hand, if a couple of widespread clients started enforcing uniqueness, it could be enough to make the ecosystem inimical to reuse. On the third hand, enforcing means failing connections that would otherwise work, so you would need a substantial security benefit to get a critical mass to enforce. Which I’m not sure is there. —Richard On Mon, Dec 16, 2024 at 09:03 Scott Fluhrer (sfluhrer) <sfluhrer= 40cisco....@dmarc.ietf.org> wrote: > Might I remind people the ML-KEM public key reuse is detectable? > > The ML-KEM public key is in the client hello, which is either in the > clear, or (in the case of ECH) is readable by the server. Hence, if the > same ML-KEM is reused, then (in the worse case) the server can detect that. > > And, if it is externally visible, I believe that the TLS WG can forbid > it. Whether it should or not is what we are debating, but I believe the > debate can't be closed on that basis. > > Has anyone considered the open questions I gave a few days ago? > > > -----Original Message----- > > From: Alicja Kario <hka...@redhat.com> > > Sent: Monday, December 16, 2024 8:42 AM > > To: Christian Huitema <huit...@huitema.net> > > Cc: Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org>; IETF TLS > > <tls@ietf.org> > > Subject: [TLS] Re: [EXTERNAL] Disallowing reuse of ephemeral keys > > > > No, the specification definitely can, and should, specify behaviours > that are > > unenforcable. > > > > When there are preferred or recommended ways of doing something, we > > should absolutely put that in writing. > > > > On Thursday, 12 December 2024 21:07:03 CET, Christian Huitema wrote: > > > I like keeping as they are. Disallowing only makes sense if that > > > prohibition can be enforced, and one of the peer refuses the > > > connection if it detects key reuse. Would we want to do that? And, > > > even if we wanted to accept the cost of refusing connections, could > > > individual nodes actually detect reuse by a peer? > > > > > > -- Christian Huitema > > > > > > On Dec 12, 2024, at 10:11 AM, Andrei Popov > > > <Andrei.Popov=40microsoft....@dmarc.ietf.org> wrote: > > > > > > > > > +1 in favor of option1. > > > > > > Cheers, > > > > > > Andrei > > > > > > From: Russ Housley <hous...@vigilsec.com> > > > Sent: Thursday, December 12, 2024 9:43 AM > > > To: Joe Salowey <j...@salowey.net> > > > Cc: IETF TLS <tls@ietf.org> > > > Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys > > > > > > I prefer option 1. > > > > > > Russ > > > > > > > > > On Dec 12, 2024, at 12:35 PM, Joseph Salowey <j...@salowey.net> wrote: > > > > > > Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of > > > ephemeral keys. This was the consensus of the working group during > > > the development of TLS 1.3. There has been more recent discussion on > > > the list to forbid reuse for ML-KEM/hybrid key exchange. There are > > > several possible options here: > > > > > > Keep things as they are (ie. say nothing, as was done in previous TLS > > > versions, to forbid the reuse of ephemeral keys) - this is the default > > > action if there is no consensus Disallow reuse for specific > > > ciphersuites. It doesn’t appear that there is any real difference in > > > this matter between MLKEM/hybrids and ECDH here except that there are > > > many more ECDH implementations (some of which may reuse a keyshare) > > > Update 8446 to disallow reuse of ephemeral keyshares in general. This > > > could be done by revising RFC 8446bis or with a separate document that > > > updates RFC 8446/bis > > > > > > We would like to know if there are folks who think the reuse of > > > keyshares is important for HTTP or non-HTTP use cases. > > > > > > > > > Thanks, > > > > > > > > > Joe, Deirdre and Sean > > > > > > > -- > > Regards, > > Alicja (nee Hubert) Kario > > Principal Quality Engineer, RHEL Crypto team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > > > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
