Thank you for the careful summary. I support publishing this document.
2026-06-24 17:00 GMT+02:00 Joseph Salowey via Datatracker <[email protected]>: > 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://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > [2] https://datatracker.ietf.org/liaison/2198/ > [3] https://datatracker.ietf.org/liaison/2151/ > [4] https://datatracker.ietf.org/liaison/2148/ > [5] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem > > _______________________________________________ > 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]
