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

[Richard Barnes <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]>
> *Sent:* Monday, December 16, 2024 9:11 AM
> *To:* Scott Fluhrer (sfluhrer) <[e-mail]>
> *Cc:* Alicja Kario <[e-mail]>; Christian Huitema <
> [e-mail]>; Andrei Popov <[e-mail]>; IETF TLS
> <[e-mail]>
> *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=
> [e-mail]> 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 <[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]
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>