I understand that we can find any arguments for or against anything nowadays, but let's standardize the codepoints which have already been assigned by IANA. There is no reason to break this document in separate documents.
-----Original Message----- From: Simon Josefsson <[email protected]> Sent: Thursday, October 9, 2025 2:50 AM To: [email protected] Subject: [EXTERNAL] [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Simon Josefsson <[email protected]> writes: > The discussion below suggests to me that X25519MLKEM768 is the running > code de-facto algorithm that ought to be on the Standards Track and > Recommended=Y and the other variants should be split off to a separate > Informational document with Recommended=N for niche usage. I realized that there is another argument for the above, see https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-16#section-4 Duplication of key shares. Concatenation of public keys in the key_exchange field in the KeyShareEntry struct as described in Section 3.2 can result in sending duplicate key shares. For example, if a client wanted to offer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768" [ECDHE-MLKEM], it would end up sending two ML-KEM-768 public keys, since the KeyShareEntry for each combination contains its own copy of a ML-KEM-768 key. So this is an argument that X25519MLKEM768 ought to be the preferred, recommended=Y and Standards Track algorithm, and that the other variants should be actively discouraged by moving them to a separate document for niche usage. This situation could also be seen as a bug in the design of draft-ietf-tls-hybrid-design but I suppose it is a bit late to change that. And the implication to have only one preferred hybrid variant for each PQ algorithm isn't unreasonable. Algorithm profileration leads to fragmented parametrized implementations and security issues. So I think the this "bug" could also be seen as a feature, even if that property probably wasn't intended initially. /Simon _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
