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