[TLS] Re: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[Bas Westerbaan <[e-mail]>]

I support prohibiting key reuse, and a quick search shows several threads
where this has been discussed before.

But concerning the issue at hand, I would love to hear about the
application where amortization is worthwhile.

It puzzles me that this is worthwhile. The thing is that ML-KEM keygen is
very fast. On my old i7 laptop it's 18k cycles. That's faster than
encapsulation (22kC) and decapsulation (22kC). This is not the whole
picture even, as a typical TLS implementation will keep the matrix A around
so that decapsulation does not have to recompute it. That reduces
decapsulation to about 8kC.

Are you perhaps generating ML-KEM private keys in a separate chip or HSM?

Best,

 Bas

On Tue, Mar 18, 2025 at 2:08 PM Viktor Dukhovni <[e-mail]>
wrote:

> On Tue, Mar 18, 2025 at 05:30:36PM +0700, Kris Kwiatkowski wrote:
>
> > Thanks for reporting that (again). Indeed, I was hoping this text
> > could be added to draft-ietf-tls-hybrid-design.
> >
> > Please, let me know if this text properly addresses your concern:
> >
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35
>
> I know that John has been quite vocal on this point, but does it actualy
> reflect WG rough consensus?  In
>
>
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35#discussion_r2000985130
>
> I ask:
>
>     Why not document the pros/cons and let implementations decide?  Some
>     clients (server-to-server routine traffic) have no reason to, and
>     get no benefit if they do, avoid session linking.  Why shouldn't
>     they amortise the cost of key generation via reuse of ML-KEM
>     ephemeral keys?
>
> --
>     VIktor.
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>