> Also, the text recommending not reusing keys could use RFC 2119 keywords.
Only -bis updates to 8446 can change normative requirements here. This was already discussed and resolved for earlier documents (I'm pretty sure it was regarding -hybrid). The latest 8446bis draft ( https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html) says "Clients and Servers SHOULD NOT reuse a key share for multiple connections" and that will flow down to hybrid kex and non-hybrid kex equally. On Fri, Feb 27, 2026, 8:17 PM Ilari Liusvaara <[email protected]> wrote: > On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote: > > 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. > > Some comments: > > - The document could expand on impact of key reuse. Known impacts > include: > > * Linking connections from the same client, which may be a privacy > risk. > * Making exploiting side channel attacks and implementation flaws > much easier. > > Also, the text recommending not reusing keys could use RFC 2119 > keywords. > > > - Also the document could expand on applicability. Known use cases > include: > > * ML-KEM-512: Constrained systems that nevertheless require security > against quantum adversaries. ML-KEM-512 is among the most efficient > quantum-resistant key exchanges known (at least among the not-too- > exciting ones). > * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) in > United States. ML-KEM-1024 is the only key exchange in the CNSA2 > profile. > > > And some notes, mainly on why I disagree with comments that this draft > should not be published: > > > - There does not seem to be any evidence that ML-KEM is weak. I think > that if ML-KEM gets badly broken, it will be for unforeseeable reasons > (which is a risk for any cryptographic algorithm, including prime- > field ECC). > > This is in contrast to things like RC4, where evidence that it is > bad did exist at the time TLS 1.0 was developed. > > Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a > serious endorsement. > > I personally think that using hybrids for encryption is worth it, but > it is close a call, and I can see that even relatively small weight > differences may tip the scale the other way. > > > - I do not think ML-DSA FO design is bad. While possibly not optimal, > I think it is very decent. I do not think passing raw entropy is > significant problem, as it seems to matter only with backdoored RNG, > which is something the extra hash in Kyber can not defend against. > > In short, I think the differences between Kyber and ML-KEM are > improvements. > > > - There are already 6 references on the construction, and I did try > giving it some good blows myself, obviously that did nothing to > stand-alone ML-KEM. > > > So I support publication. > > > > > -Ilari > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
