Here's a stab at more text around hybrid vs not-hybrid in Security
Considerations:
# Security Considerations {#security-considerations}
This document defines standalone ML-KEM key establishment for TLS 1.3.
Hybrid key establishment mechanisms, which support combining a post-quantum
algorithm with a traditional algorithm such as ECDH, are supported
generically via {{HYBRID}} with some concrete definitions in
{{ECDHE-MLKEM}}. 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.
+for its security. Proponents of hybrid PQ/T key establishment generally
+consider it a conservative approach to deployment of newer post-quantum
+schemes alongside older traditional schemes, retaining at least the
security
+currently offered by traditional algorithms.
On Fri, Feb 27, 2026 at 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]
