Thank you for your review, I think all of these comments are addressed by version 10, except for the RFC 9847 normative/informative question— other RFCs list this as Informative, and I asked my AD if Informative is correct, she said yes, this is an Informative reference.
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/10/ On Fri, Aug 7, 2026 at 12:25 PM Stewart Bryant via Datatracker < [email protected]> wrote: > 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 > > ========== > > > >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
