On Wed, Jun 24, 2026 at 08:00:07AM -0700, Joseph Salowey via Datatracker wrote: > > 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.
In addition to this question, I will also opine on whether my objections to publication of an earlier version (-05) still hold. > 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. The combination of this clear documentation of preference for hybrid (in the general case), combined with the updates to the security considerations text in the -08, are adequate to address my earlier objections on the grounds that the WG was taking inconsistent positions in different documents. While I would love to see a broader "best practices" document that discusses the various tradeoffs and risk assessments involved in a decision to use pure-ML-KEM vs a hybrid construction, akin to what Stephen Farrell propsoed early in the WGLC, I don't see a need to block publication of this document until such a BCP exists. (As an aside, I think we actually have pretty strong consensus on the technical facts of the form "if <X> and <Y> happen, you should do <Z>", and the vehement disagreement stems from assessments of which <X>/<Y> combinations are likely to happen or given more weight. But that should probably be a matter for discussion alongside the purported BCP, not this thread.) > - 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. Getting back to the primary question being asaked, about whether the WG should publish a document for standalone ML-KEM, I'm mostly indifferent. As has been noted many times already, the codepoints already exist and so do implementations, so having the WG itself publish the document adds very little technical value (and, as has also been noted many times already, the risk of being misinterpreted as an endorsement for generic use despite the clear text in the content of the document), but on the other hand the document itself is concise and clear about the protocol specification and how to obtain the IETF's current guidance on algorithm usage, and most of the time when an IETF WG has a document in such a state it ends up getting published. That, combined with the liaison statements mentioned here, lead me to lean slightly towards publishing a document in this space. -Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
