[Gen-art] draft-ietf-tls-mlkem-09 ietf last call Genart review

[Stewart Bryant via Datatracker <[e-mail]>]

Document: draft-ietf-tls-mlkem
Title: ML-KEM Post-Quantum Key Agreement for TLS 1.3
Reviewer: Stewart Bryant
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-mlkem-09
Reviewer: Stewart Bryant
Review Date: 2026-08-07
IETF LC End Date: 2026-08-13
IESG Telechat date: Not scheduled for a telechat

Summary: A well written draft that the can be published. There are no major
issues and just a few nits that could usefully be fixed for the benefit of the
reader and to save work by the RFC Editor team.

In doing the review I did something I have never done before. AFTER reading the
draft myself and preparing comments I asked Claude for a review. I did not do
blind copy across, but included a few issues that I had missed and thought
worthy of of drawing to the attention of the IESG.

There was one comment concerning the use of the term hybrid that was outside my
domain of security knowledge and thus I did not know if I should include the
comment. The consolidated AI review is at the end of the following web page.

https://claude.ai/share/65e221cd-39c5-480e-b7b0-23a5daff54fb

Major issues:None

Minor issues:None

Nits/editorial comments:

Nits picked up

 == Missing Reference: 'DUALEC-TLS' is mentioned on line 236, but not defined

  == Unused Reference: 'DUALECTLS' is defined on line 328, but no explicit
     reference was found in the text

This is a typo

=========
181        Implementations MUST NOT reuse randomness in the generation of ML-KEM
182        ciphertexts— it follows that ML-KEM ciphertexts also MUST NOT be
183        reused.

SB> Perhaps

Implementations MUST NOT reuse randomness in the generation of ML-KEM
           ciphertexts.  From this it also follows that  ML-KEM ciphertexts
           MUST NOT be reused.
=========
204        [CHSW22] [CZCJWH25] [ZJZ24]; ML-KEM's IND-CCA security exceeds the

SB> IND-CCA is not in the official list of well known abbreviations and should
be expanded (no * symbol in
https://rpc-wiki.rfc-editor.org/doku.php?id=abbrev_list

=========

246        Section 6 of [RFC9847].

SB> RFC9847 looks normative, should it be moved to the normative reference list?

==========

320        [CZCJWH25] "Post-Quantum {TLS} 1.3 Handshake from {CPA}-Secure {KEMs}
321                   with Tighter Reductions", n.d.,
322                   <https://eprint.iacr.org/2025/1748.pdf>.

SB> The documents itself has a date - should this be added to the reference?

=========

398        Thanks to Douglas Stebila for consultation on the draft-ietf-tls-
399        hybrid-design design, and to Scott Fluhrer, Eric Rescorla, John Preuß
SB> Double use of “design" although perfectly acceptable although perhaps
"---design approach" would read better

==========