[TLS] Re: [EXTERNAL] Disallowing reuse of ephemeral keys

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

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 <[e-mail]>
> Sent: Monday, December 16, 2024 8:42 AM
> To: Christian Huitema <[e-mail]>
> Cc: Andrei Popov <Andrei.Popov=[e-mail]>; IETF TLS
> <[e-mail]>
> 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=[e-mail]> wrote:
> >
> > 
> > +1 in favor of option1.
> >
> > Cheers,
> >
> > Andrei
> >
> > From: Russ Housley <[e-mail]>
> > Sent: Thursday, December 12, 2024 9:43 AM
> > To: Joe Salowey <[e-mail]>
> > Cc: IETF TLS <[e-mail]>
> > Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys
> >
> > I prefer option 1.
> >
> > Russ
> >
> >
> > On Dec 12, 2024, at 12:35 PM, Joseph Salowey <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]