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
