Subject: [TLS] Re: [EXTERNAL] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
From: Viktor Dukhovni <[email-masked]>
To: [email-masked]
Date: Fri, 3 Jan 2025 12:00:11 +1100
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

On Wed, Dec 11, 2024 at 12:28:32AM +0000, Kris Kwiatkowski wrote:

> Following the feedback from the last TLS meeting at IETF@121, I have opened
> this PR to change the name from X25519MLKEM768 to MLKEM768X25519. This
> change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2).
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26

I've registered a dissenting view on the rename:

    https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26#issuecomment-2568568522

The relevant paragraph in Section 3.2 of hybrid design:

    For a hybrid key exchange, the key_exchange field of a KeyShareEntry
    is the concatenation of the key_exchange field for each of the
    constituent algorithms. The order of shares in the concatenation
    MUST be the same as the order of algorithms indicated in the
    definition of the NamedGroup.

says nothing about naming (bikeshed colours).  It talks about the
"definition of the NamedGroup".  The name is NOT the definition, the
name is just an indentifier for that definition, the latter is specified
in the RFC that defines the group.  There's no need whatever to waste
time renaming.

> > 2. **Changing the order of shares in Secp256r1MLKEM768**.
> >    - The current order is based on requirements from SP800-56C-r2, and

Once the code point has been registered for some time and implemented by
multiple libraries, changing the order should result in a new codepoint,
and be associated with a new group definition and name.

-- 
    Viktor.