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.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
