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
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
