[TLS] Re: [EXTERNAL] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

["Dang, Quynh H. (Fed)" <[e-mail]>]

Hi Joe and Sean,

I support publishing the document as an RFC.

Regards,
Quynh. 

> -----Original Message-----
> From: Joseph Salowey via Datatracker <[e-mail]>
> Sent: Wednesday, June 24, 2026 11:00 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-
> 07-08)
> 
> This message initiates a new Working Group Last Call for draft-ietf-tls-
> mlkem[1], which defines standalone ML-KEM key establishment for TLS 1.3.
> The main question before the working group is: "Should the working group
> publish a document specifying stand alone ML-KEM?". If there is rough
> consensus then we will push to refine and publish the document; otherwise,
> we will stop discussing the draft and not progress it. Please respond to this call
> indicating whether you support publishing a document specifying a stand
> alone ML-KEM. Please refrain from further discussion on this topic as most
> arguments have been discussed multiple times.
> 
> Why are we holding this consensus call now?
> 
> Significant developments have occurred both within this document and in the
> broader TLS ecosystem to address the concerns raised in the last WGLC.
> Therefore, the third consensus call is warranted. We ask the working group to
> consider document publication in light of these recent changes:
> 
> - 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.
> 
> - Liaisons: We received liaison statements from multiple SDOs including  O-
> RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing support for the
> publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide
> a stable normative reference.
> 
> Please note that a third-party IPR disclosure exists [5] against this document
> regarding patents related to the underlying ML-KEM algorithm. This IPR
> declaration has not changed since the last WGLC. As a reminder, per BCP 79,
> the IETF takes no stance on the validity of patent claims, and the working
> group may decide to proceed with a technology despite IPR disclosures if it
> decides that such use is warranted.
> 
> Conduct Reminder: Given the heated nature of previous discussions on this
> topic, participants are strongly reminded to adhere to the IETF Code of
> Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback
> professional, technical, and focused on the document's text.
> 
> This working group last call will end on 2026-07-08.
> 
> Joe and Sean
> 
> [1]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-tls-
> mlkem%2F&data=05%7C02%7Cquynh.dang%40nist.gov%7C5438bcf1cd0f4
> d36346408ded201786c%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7
> C0%7C639179100917984819%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC
> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G5lFeyNkfOkvIMdNfeXTFJB
> wp%2Bsx0jXnEHMp0gJOg%2B8%3D&reserved=0
> [2]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fliaison%2F2198%2F&data=05%7C02%7Cquynh.dang%40ni
> st.gov%7C5438bcf1cd0f4d36346408ded201786c%7C2ab5d82fd8fa4797a9
> 3e054655c61dec%7C0%7C0%7C639179100918025685%7CUnknown%7CT
> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ro
> rBf%2F1d6V3l01t%2F8RtRGcQDJrXnODy3DVtctR8gdzM%3D&reserved=0
> [3]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fliaison%2F2151%2F&data=05%7C02%7Cquynh.dang%40ni
> st.gov%7C5438bcf1cd0f4d36346408ded201786c%7C2ab5d82fd8fa4797a9
> 3e054655c61dec%7C0%7C0%7C639179100918047314%7CUnknown%7CT
> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=X0
> 1c0lNPPnw1ZAq7CufDUKUrlr%2BYamwvFotEGyBWuLw%3D&reserved=0
> [4]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fliaison%2F2148%2F&data=05%7C02%7Cquynh.dang%40ni
> st.gov%7C5438bcf1cd0f4d36346408ded201786c%7C2ab5d82fd8fa4797a9
> 3e054655c61dec%7C0%7C0%7C639179100918066347%7CUnknown%7CT
> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZF
> 2BhUIJaUpcexJi0w1xtN8zG9%2BmXXyV19cKXPr3MV0%3D&reserved=0
> [5]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-ietf-
> tls-
> mlkem&data=05%7C02%7Cquynh.dang%40nist.gov%7C5438bcf1cd0f4d36
> 346408ded201786c%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0
> %7C639179100918084747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OuVVELyBIEdKV75CK5qkF%2F
> MD65fJ1PMdgDoZCFRpDyg%3D&reserved=0
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]