[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

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

Hi John,

> I completely agree that NIST requirements should be followed but explicitly mention 7.2 and not other mandatory requirements like the decapsulation input check in 7.3 might make the reader wondering if the mandatory requirements in e.g., 7.3. can be skipped, which I would disagree with.

As with SSH, only the ciphertext length check in section 7.3 of FIPS203 apply to the client at decapsulation time because the other two check the decapsulation key which the client has generated itself and thus are unnecessary. The ciphertext length check is already in normative language in the text.

> FIPS 203 forbids reuse of ephemeral keys,

I don't get that. What text in FIPS 203 dictates that each keypair needs to be used only once? I missed it.

I would be fine making the "still recommended that implementations avoid re-use of any keys (including ML-KEM keys)" normative, but I think 8446-bis is more suitable for it. The draft-ietf-tls-mlkem is not a good place to make such broad declarations about TLS 1.3 imo.



From: John Mattsson <john.mattsson=[e-mail]>
Sent: Friday, November 7, 2025 2:12 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)


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.

Hi,

I support publication as long as the major comments below are addressed.

I think it is correct to publish the "groups" as RECOMMENDED = N and then discuss all algorithms together at a later stage. I can understand why some people strongly prefer hybrids to protect against implementation bugs, but I do not see why standalone ML-KEM should be marked as discouraged. It is a very well-studied algorithm believed to provide very good security. European governments are now stating that they have the highest confidence in ML-KEM. I think the recommended level should be above P-256, X25519, and all other algorithms providing zero security against quantum attackers.

Major:

- "The KeyShareClientHello includes a list of KeyShareEntry structs that
   represent the key establishment algorithms the client supports.  For
   each parameter of ML-KEM the client supports, the corresponding
   KeyShareEntry consists of a NamedGroup that indicates the appropriate
   parameter, and a key_exchange value that is the pk output of the
   KeyGen algorithm."

This seems like an explanation of the "supported_groups" extension, not the KeyShareClientHello. My understanding is that "supported_groups" represent the key establishment algorithms the client supports and that KeyShareClientHello is a subset. I suggest removing text (incorrectly) duplicating RFC 8446.

- "For all parameter sets, the server MUST perform the encapsulation key
   check described in Section 7.2 of [FIPS203]"

I completely agree that NIST requirements should be followed but explicitly mention 7.2 and not other mandatory requirements like the decapsulation input check in 7.3 might make the reader wondering if the mandatory requirements in e.g., 7.3. can be skipped, which I would disagree with.

-  "TLS 1.3 does not prohibit key re-use; some implementations may use
   the same ephemeral public key for more than one key establishment at
   the cost of limited forward secrecy.  Care must be taken to ensure
   that keys are only re-used if the algorithms from which they are
   derived are designed to be secure under key-reuse.  ML-KEM's IND-CCA
   security satisfies this requirement such that the public key/secret
   key pair can be used long-term or re-used without compromising the
   security of the keys.  However, it is still recommended that
   implementations avoid re-use of any keys (including ML-KEM keys) to
   ensure perfect forward secrecy."

This is wrong in many ways.

FIPS 203 forbids reuse of ephemeral keys, which applies to this draft. IETF specifications referring to FIPS 203 may not use the same ephemeral public key for more than one key establishment. TLS WG has not discussed violating NISTs requirements, and I suspect most people in IETF do not want to violate NIST requirements for ML-KEM, I certainly don't.

Ephemeral keys should be independent and reusing them has a large number of negative security consequences. As stated in NIST SP 1800-37 "Addressing Visibility Challenges with TLS 1.3 within the Enterprise High-Level Document":

"Reuse of a key share allows passive observers to correlate different connections. This specification discourages client and server reuse of a key share for multiple internet connections. Reusing key shares outside protected facilities can also expand the impact of security breaches."

And the above statement from NIST is too soft. If you believe in zero trust rather than perimeter security, reusing key shares can expand the impact of security breaches even within protected facilities. Moreover, reusing key shares also weakens post-compromise security.

Minor:

- I think the draft should mention that ML-KEM is very very fast. Suggestion: "Optimized implementations of ML-KEM achieve key generation, encapsulation, and decapsulation operations that are faster than elliptic-curve Diffie-Hellman mechanisms (such as X25519 or P-256) on modern 64-bit CPU architectures with vector instructions."

- [AVIRAM], [DOWLING], [FO], [HHK], [HPKE], [hybrid], [LUCKY13], [RACCOON] are not used and should be removed.

- OLD: key establishment mechanism (KEM)
  NEW: key encapsulation mechanism (KEM)

Cheers,
John