Document: draft-ietf-tls-ecdhe-mlkem Title: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Reviewer: Dale Worley Review result: Ready with Nits
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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
