As with the old document, I support publication. (And just like Soatok, I have a blog post about it if further argument as to why is wanted)
On Tue, Jun 30, 2026 at 7:48 AM Soatok Dreamseeker <[email protected]> wrote: > I support publication of this document. > > Happy to share my reasoning if anyone is curious (but I already posted it > on my blog for the curious and impatient). > > On Wed, Jun 24, 2026 at 11:01 AM Joseph Salowey via Datatracker < > [email protected]> 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] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
