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

[Viktor Dukhovni <[e-mail]>]

On Sun, Mar 09, 2025 at 02:02:55PM +0000, John Mattsson wrote:

> Viktor Dukhivni wrote:
> >However, you'll be thrilled to learn that it is not possible for a TLS
> >server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
> >ML-KEM keyshare.
> 
> Yes, that solves half the problem, but I would also like my servers to
> not talk to clients reusing key shares with other servers.

I've seen no evidence that TLS client implementations exist or are being
planned that will use *long-term* ML-KEM keys to generate keyshares.
Any occasional short-term reuse is much less riskly in ML-KEM than it
would be in ECDH.  If ML-KEM is secure enough to use at all, it should
be secure enough for some short-term key reuse.

I very much expect that there will not be separate code points for or a
prohibition against key reuse, and nevertheless key reuse will be
infrequent and at most short-term to amortise initial keygen most, with
most of the benefit gained in the first O(10) users, and rapidly
diminishing gains thereafter.

The behaviour of mainstream implementations will not stay secret, and
nobody will want to be seen as negligent of best practice.  The guidance
should be that single-use is recommended, but otherwise reuse should be
rather limited both in temporal duration and use count.  Guidance to
encourage fresh keys every ~5 minutes and every ~10 users is not
unreasonable.

And if some day we learn that quantum computers are impossible, we'll go
back to just X25519, or if CRQCs arrive, we'll stop using hybrids and
will use whichever pure PQ algorithms are preferred at that time.

-- 
    Viktor.