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

["Kampanakis, Panos" <[e-mail]>]

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 <simon=[e-mail]> 
Sent: Thursday, October 9, 2025 2:50 AM
To: [e-mail]
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 <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