> there may be some subtlety around the new text claiming that non-reuse of the randomness input for ML-KEM implies non-reuse of ML-KEM ciphertexts, though -- a strict reading of this prohibition might, for example, come into conflict with the DTLS retransmission rules where we do need to reuse the ciphertext because we are logically retransmitting the packet rather than re-doing the cryptographic operation. Probably we can get around this by clarifying that such ciphertexts "MUST NOT be reused in a different handshake".
Re-transmitting the ML-KEM ciphertext is doing the 'other side' of then cryptographic operation to establishment the shared secret as part of the handshake. We can clarify to make explicit that this is the ML-KEM ciphertext as part of the ServerHello key_share only, not any other further ciphertext of the connection (this also applies to -hybrid-design) On Fri, Feb 27, 2026, 4:54 PM Benjamin Kaduk <bkaduk= [email protected]> wrote: > On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote: > > This Message Is From an Untrusted Sender > > You have not previously corresponded with this sender. > > > > > > 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: > > > > [1]https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > > > > The diff with the previous WGLC draft (-05) is here: > > > > [2] > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&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. > > Thanks Dierdre for the link to the diff with the working copy [0]. > > Looking at that in the context of my review for the previous WGLC [1], I'm > glad > to see that the text implicitly redefining KeyShare semantics has been > removed. > > I'm also happy to see that text has been added to list specific use cases > where > standalone PQ (i.e., non-hybrid) key exchange is perceived to be useful or > is > mandated. However, that text alone does not address the crux of my concern > with the heading "Security considerations of non-hybrid", which I will try > to > distill to a core idea here: In {{{HYBRID}}, we say that (in the general > case) > "the security community does not necessarily have as much confidence in > [the] > fundamental security" of the PQ key-exchange algorithms as it does in > (EC)DHE, > with the corresponding implication that (again, in the general case) hybrid > constructions should be preferred over pure-PQ, at present. In this > draft, we > promulgate some pure-PQ key-exchange algorithms with no commentary about > how > these specific algorithms relate to the general guidance in {{HYBRID}} > against > such algorithms, which appears to put the two documents in conflict; I am > claiming that we need to have some explicit text in this document to > resolve > the conflict with our other document (which, we recall, is not even an RFC > yet -- it's still in the RFC Editor's queue). > > I see at least three possibilities here: (1) ML-KEM falls into the "though > not > all" bucket of "many (though not all) post-quantum algorithms under > consideration are relatively new"; (2) the security community has changed > its > mind and has equivalent confidence in the fundamental security of at least > ML-KEM (if not other PQ algorithms) and the fundamental security of > (EC)DHE; or > (3) the security community retains its concerns in the general case but > some > use cases require non-hybrid/pure PQ even in the face of those concerns, > so we > provide pure-ML-KEM key-exchange solely for those limited use cases, with > the > general recommendation to use hybrids remaining in place. > > I don't think we're in (1). I suppose that the (voluminous) ongoing WGLC > thread (I'm not fully caught up) is in a certain sense a debate about > whether > (2) holds, but IMHO we need fairly strong consensus in order to overturn a > preexisting WG consensus position, especially one so recently determined, > so I > believe that we are in case (3). (If we're in (2), we should pull > draft-ietf-tls-hybrid-design from the RFC Editor's queue.) If we are > indeed in > case (3), I would have expected this document to include some text > acknowledging that the mechanisms in this draft are an exception to the > current > generic guidance and are only expected to be used in specific limited > scenarios. Perhaps something like (including some existing text from this > document as transition/context): > > % Hybrid mechanisms provide security as long as at least one of the > component > % algorithms remains unbroken, such as combining quantum-resistant and > % traditional cryptographic assumptions. Standalone ML-KEM relies on > % lattice-based and hash function cryptographic assumptions for its > security. > % The sense of the security community recorded in {{HYBRID}} is that (due > in > % large part to their newness) the general level of confidence in PQ > algorithms > % is lower than the level of confidence in (EC)DHE algorithms as relates to > % cryptanalysis in the absence of quantum computers, with the corollary > that > % hybrid constructions should be used in the absence of a particular > motivation > % to use a pure-PQ algorithm. The use cases identified in {{motivation}} > % constitute some scenarios where there is a particular motivation to avoid > % using a hybrid construction (though are not an exhaustive list). > Regardless, the > % decision to use a pure-PQ algorithm rather than a hybrid should be made > on a > % case-by-case basis; the generic recommendation remains to use a hybrid > % algorithm at the time of this writing. > > Additionally, I think there may be some subtlety around the new text > claiming > that non-reuse of the randomness input for ML-KEM implies non-reuse of > ML-KEM > ciphertexts, though -- a strict reading of this prohibition might, for > example, > come into conflict with the DTLS retransmission rules where we do need to > reuse > the ciphertext because we are logically retransmitting the packet rather > than > re-doing the cryptographic operation. Probably we can get around this by > clarifying that such ciphertexts "MUST NOT be reused in a different > handshake". > > I also agree with other reviewers that we may want to do more to ensure > that the > security considerations for reuse of ephemeral key shares are sufficiently > prominent (whether via including them in this document or by specific > reference, though 8446bis §C.4 seems to only cover the tracking-vector > aspect > of things). > > Thanks, > > Ben > > [0] > https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05..main > [1] https://mailarchive.ietf.org/arch/msg/tls/jKyjctDtgAo_tvbpC5Z2-nyW75I/ > > _______________________________________________ > 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]
