Trying to pull this up to its own subject
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 8:29 PM Deirdre Connolly <[email protected]>
wrote:
> 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]
