I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document:  draft-ietf-tls-ecdhe-mlkem-03
Reviewer:  Dale R. Worley
Review Date:  2026-01-13
IETF LC End Date:  2026-01-20
IESG Telechat date:  [not known]

Summary:

    (This is a review of the exposition of draft-ietf-tls-ecdhe-mlkem-03,
    not a security analysis.)

    This draft is basically ready for publication, but has nits that
    should be fixed before publication.

Nits/editorial comments:

2.  Motivation

   *  The first one uses X25519 [rfc7748], is widely deployed, and often
      serves as the most practical choice for a single PQ/T hybrid
      combiner in TLS 1.3.

For the naive reader, it would help if "PQ/T" was expanded.  ("PQ/T"
is not in the RFC Editor well-known abbreviation list.)

2.1.  Terminology

   The [hybrid] document defines a "hybrid" key exchange as one that
   combines a traditional key exchange with a next-generation key
   exchange.  This document uses the term "hybrid" in the same way.

The reference [hybrid] says:

 Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if a way is found to defeat the encryption for all but
   one of the component algorithms. 

For the naive reader, it would help if the latter explanation was
added to the explanation in sec. 2.1, as that would explain what the
"combines" is and why it is valuable.

7.  IANA Considerations

All three registrations are for "TLS Supported Groups" and include:

   Recommended:  N
   
The IANA table TLS Supported Groups
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)
describes "Recommended" with:

    If the "Recommended" column is set to "N", it does not necessarily
    mean that it is flawed; rather, it indicates that the item either
    has not been through the IETF consensus process, has limited
    applicability, or is intended only for specific use cases. [...]

However, it appears that once the document is approved, these three
key exchange systems will quality for "Recommended:  Y", as they will
have IETF consensus, appear to be secure "in the post-quantum world",
and are FIPS-approved (when used properly).  If "Recommended: N" is
intended, some explanation for this (e.g., the limits of
applicability) should be provided.

[END]