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]
