Oh, to be clear, I totally agree we can and should forbid reuse. That's why Joe's option (3) was my most preferred option in my first reply on this thread.
I thought we were talking about "unenforceable" / "detectable". My point being: * Yes, reuse is detectable / a ban is enforceable in principle * In practice, I doubt that it will be enforced by any significant fraction of clients, regardless of anything the IETF says * Even given that, we should still forbid reuse --RLB On Mon, Dec 16, 2024 at 9:25 AM Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote: > 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> 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
