Good morning, I am a long time lurker but have never published to the list before (I think), so feel free to adjust your opinion of my view accordingly.
I support publication of this document. As a result of CNSA 2.0 preferring pure-PQ, a number of major libraries have already implemented either all code points or some of them: - OpenSSL: https://github.com/openssl/openssl/blob/e60d940b29504b7b1f15d1fe597ae9cdde701c8a/providers/common/capabilities.c#L181-L183 - BoringSSL: https://github.com/google/boringssl/blob/be08ef39e96191146b978ecbfd8eb8c3b50babb9/ssl/ssl_key_share.cc#L446 - aws-lc and s2n-tls: https://github.com/aws/aws-lc/blob/6283365b1d43abadfa9b997812cef06b095f7f04/ssl/ssl_key_share.cc#L682-L684 https://github.com/aws/s2n-tls/blob/e30701f7880eb5b87516eecc2d0fa2b79f014344/tls/s2n_kem.c#L66 I think that having tls-wg have oversight of the specification is better than not, given implementation will likely happen. I believe recommended=N is sufficient to say that hybrids are currently the preferred choice. That said, I do not believe the risk of ML-KEM (and ML-DSA) to be severe: there is no known cryptanalysis currently exploiting rank >=2 module structure at these parameters that performs better than generic lattice reduction. Module-LWE also has a (granted, an asymptotic) worst-case-to-average-case reduction - something neither RSA nor ECDLP had. Kind regards, Antony On Wed, 2026-06-24 at 08:00 -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. > > 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]
