Hmmmm, I see we attach different meanings to the word “forbid”. You take forbid as “if the client does it, it doesn’t interoperate”. As you point out, in practice servers won’t do it (because it’d be quite difficult for them, and for very little benefit).
I take forbid as “make a statement in the RFC, so that if they do it, they’re not in compliance”. This is more standards language than interoperability, with the possibility of compliance being externally testable (and not that it would be tested on a routine basis). And (on a different note) to recap my two open questions: * Do the existing TLS security proofs assume that there will be no public key reuse? As the TLS security proofs are considered a step forward, staying within their assumptions would appear to be important (and if they make that assumption, that means that we really have to forbid reuse). * Assuming that the security proofs work with key reuse, I can see a case where a highly constrained implementation might want to use key reuse, possibly to extend battery life. Would the working group buy such an argument from such an implementation? I ask this because that’s the only reason I can think of that a client would want to do key reuse. From: Richard Barnes <r...@ipv.sx> Sent: Monday, December 16, 2024 9:11 AM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Cc: Alicja Kario <hka...@redhat.com>; Christian Huitema <huit...@huitema.net>; Andrei Popov <andrei.po...@microsoft.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] Re: [EXTERNAL] Disallowing reuse of ephemeral keys 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<mailto: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<mailto:hka...@redhat.com>> > Sent: Monday, December 16, 2024 8:42 AM > To: Christian Huitema <huit...@huitema.net<mailto:huit...@huitema.net>> > Cc: Andrei Popov > <Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>; > IETF TLS > <tls@ietf.org<mailto: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<mailto:40microsoft....@dmarc.ietf.org>> > > wrote: > > > > > > +1 in favor of option1. > > > > Cheers, > > > > Andrei > > > > From: Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>> > > Sent: Thursday, December 12, 2024 9:43 AM > > To: Joe Salowey <j...@salowey.net<mailto:j...@salowey.net>> > > Cc: IETF TLS <tls@ietf.org<mailto: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<mailto: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<http://www.cz.redhat.com> > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > > _______________________________________________ > TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> > To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
