> At the very least, it should be obvious in this case that, even though 8446 gives permission, the server cannot reuse the key share (ML-KEM ciphertext) if the client uses different public keys. Hence, the text in 8446 cannot be considered the final word, it may need to be adjusted according to later requirements.
An honest or non-buggy server peer could not/would not, as the ciphertext would not decapsulate by the client. In the current text we say you cannot reuse encapsulation randomness either. One certainly /can/ send collected ciphertexts to a peer who cannot decapsulate them On Sat, Feb 28, 2026, 2:34 PM Scott Fluhrer (sfluhrer) <[email protected]> wrote: > Actually, I'm pretty sure a newer RFC can override an older one. > > At the very least, it should be obvious in this case that, even though > 8446 gives permission, the server cannot reuse the key share (ML-KEM > ciphertext) if the client uses different public keys. Hence, the text in > 8446 cannot be considered the final word, it may need to be adjusted > according to later requirements. > > Similarly, this draft could say "clients MUST NOT reuse an ML-KEM public > key, but instead MUST generate a fresh one for each exchange from fresh > randomness". > > On the other hand, the appropriate question is "should it?". That is the > question we should be asking ourselves. > > If you ask my opinion, I would lean towards "yes, it should". Generating > fresh ML-KEM public keys is cheap, and it gives several minor security > benefits (strong PFS if you don't forget to zeroize them when you're done > with this, and making side channel attacks stronger). > > ------------------------------ > *From:* Deirdre Connolly <[email protected]> > *Sent:* Friday, February 27, 2026 4:05 PM > *To:* Ilari Liusvaara <[email protected]> > *Cc:* <[email protected]> <[email protected]> > *Subject:* [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends > 2026-02-27) > > > 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]
