Hi all, I support publication of draft-ietf-tls-mlkem-08.
My review was mostly around the security-considerations text and the hybrid-vs-standalone concern. I think -08 now draws the right distinction: it gives implementers stable specification text for standalone ML-KEM, while the surrounding registry signals and deployment guidance still make the WG preference for hybrid clear. In particular, X25519MLKEM768 is the Recommended: Y hybrid, while the standalone ML-KEM groups in this draft remain Recommended: N. The two other changes also address the main concerns I had: key-share reuse is now handled by the 8446bis MUST NOT, and the formal-analysis material is cited at a useful level without making one model carry more weight than it should. So I do not read publication as saying standalone should be preferred over hybrid. I read it as documenting the standalone mechanism with explicit constraints and signals, which seems useful for implementers and for SDOs that need a stable TLS reference. Best, Songbo On Wed, 24 Jun 2026 17:34:52 +0200, Muhammad Usama Sardar [email protected] wrote: Hi Deirdre, all, Thank you for addressing all my technical objections in -08. I have closed the remaining last issue [0]. On 24.06.26 17:00, Joseph Salowey via Datatracker wrote: The main question before the working group is: “Should the working group publish a document specifying stand alone ML-KEM?”. I have ‘no opinion’ on this question and WGLC. - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate consensus call, the WG agreed to promote the X25519MLKEM768 hybrid group to Recommended: Y in the IANA registry. Consequently, the IANA registry will reflect a clear community preference for a hybrid because Recommended: Y clearly indicates this while the standalone ML-KEM groups defined in this draft remain Recommended: N. The updated security considerations in [1] reference the IANA registry to emphasize this preference. - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recently reached consensus to explicitly prohibit key share reuse across connections in TLS 1.3. The new text changes the guidance from SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding static key reuse and its associated privacy and forward-secrecy risks for ML-KEM. - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid KEM groups in TLS 1.3. This supports other results which show that KEMs are secure when used in TLS 1.3 and that hybrid groups are secure even if one of the components is compromised. Thanks a lot for all the above three. Best regards, -Usama [0] https://github.com/tlswg/draft-ietf-tls-mlkem/issues/18
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
