Hi Joe and Sean, I support publishing the document as an RFC.
Regards, Quynh. > -----Original Message----- > From: Joseph Salowey via Datatracker <[email protected]> > Sent: Wednesday, June 24, 2026 11:00 AM > To: [email protected]; [email protected]; [email protected] > 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
