[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Simon Josefsson <[e-mail]>]

Simon Josefsson <simon=[e-mail]> 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