[TLS] Re: draft-ietf-tls-mlkem-09 ietf last call Genart review

[Deirdre Connolly <[e-mail]>]

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 <
[e-mail]> 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
>
> ==========
>
>
>
>