Hi,

I support publication iff all text related to “key reuse” is removed. In its 
current form, I do not believe -07 should be published.

Major Comments:

- FIPS 203 states that:

“the licensed patents be freely available to be practiced by any implementer of 
the ML-KEM algorithm as published by NIST.”

“requirements for the secure use of KEMs in applications, see SP 800-227.”

A reused key is, by definition, a static key. SP 800-227 imposes additional 
requirements for static keys compared to ephemeral keys. The draft does not 
explain how an implementer can satisfy these requirements. This creates 
potential non-conformance with NIST specifications.

-  The draft does not describe the significant security and privacy problems 
associated with key reuse. IND-CCA is a theoretical property of the algorithm. 
However, the security and privacy problems are related to the reuse of keys in 
the TLS 1.3 protocol in deployments.

Minor Comments:

- The discussion of randomness reuse in ciphertexts and references to SP 
800-227 do not belong in a “key reuse” section. Ciphertexts are not keys, and 
SP 800-227 contains broader guidelines and requirements beyond static keys.

- “The client's shares are listed in descending order of client preference; the 
server selects one algorithm and sends its corresponding share.”

The server may also select no share and respond with a handshake_failure or a 
HelloRetryRequest (HRR). Since this is already specified in RFC 8446, it would 
be better to remove this text and simply reference RFC 8446.

- Section 5.1 appears to ​mix different concepts: hybrids, PQ/T hybrids, and 
lattice-based PQ/T hybrids. I assume the person asking for this section wanted 
a comparison with [ECDHE-MLKEM]. I suggest doing that. In the future, PQ/T 
hybrids will likely become less common, but it is unclear whether other hybrids 
(e.g., ML-KEM + HQC-KEM) will gain adoption.

Cheers,
John

From: Joseph Salowey <[email protected]>
Date: Thursday, 12 February 2026 at 20:06
To:
<[email protected]>
Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)


This message starts the second Working Group Last Call for the pure ML-KEM 
document (draft-ietf-tls-mlkem-07).


The file can be retrieved from:

https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

The diff with the previous WGLC draft (-05) is here:


https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html<https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>


The main focus of this WGLC is to review new text providing more context around 
the use of pure ML-KEM.  For those who indicated they wanted this text, please 
let us know if the new text satisfies you and if you support publication. This 
working group last call will end on February 27, 2026.


Thank You.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to