[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Viktor Dukhovni <[e-mail]>]

On Wed, Apr 02, 2025 at 08:07:49AM +0400, Loganaden Velvindron wrote:

> I share the same view as Martin. I also support adoption but we should
> be very careful proceeding forward.

It seems fair to assume at this point that even if/when adopted the
"Recommended" status will be "N".  That aside, the IANA codepoints are
already assigned, and the protocol payloads are obvious (c2s ek, s2c
ciphertext, both from FIPS 203, and by the clear analogy with the
widely used composites).

Implementations are already deployed, though not necessarily enabled in
default configurations.  For example, in OpenSSL 3.5.0 all three
variants are implemented, but none are in the default value of the
supported groups extension:

    $ openssl list -tls1_3 -tls-groups | tr ':' '\n' | grep -i mlkem
    MLKEM512
    MLKEM768
    MLKEM1024
    SecP256r1MLKEM768
    X25519MLKEM768
    SecP384r1MLKEM1024

The default supported groups are:

    "?*X25519MLKEM768 / ?*X25519:?secp256r1 / ?X448:?secp384r1:?secp521r1 / ?ffdhe2048:?ffdhe3072"

which means that a client key share is by default sent for
"X25519MLKEM768" and it is chosen by the server (HRR if necessary) when
mutually supported.  A client key share is also sent for "X25519" and it
is otherwise chosen by the server when mutually supported. Otherwise,
"secp256r1" (P-256) is chosen, or else one of the remaining EC groups,
or else either of the FFDHE groups.

Some wordsmithing aside, I don't see that there's much to do here, the
protocol details won't change.  Key in clients reuse will be rare, and
non-catastrophic, interoperable key reuse in servers is not possible.

It won't much difference whether this is published by the WG or the ISE,
except as to who gets to do the wordsmithing.  If the WG would rather
not deal with it, the ISE would likely save the authors a lot of bother.

If the WG would like to tweak security considerations, or otherwise
polish the text, then adoption is the opportunity to do so.

-- 
    Viktor.