Can I kindly ask if there is evidence that can be provided for your statements about the numbers, and more info on the weights / method you apply to weigh answers, from both sides ?
I imagine you have a table/a scheme/something, with participants, an established method for the weights, weights associated to each person on both sides, other elements you may have considered relevant .... Thank you for your kind attention Fabiana Da Pieve Team Leader Post-Quantum Cryptography European Commission DG Communications Networks, Content and Technology Unit C4 – Emerging & Disruptive Technologies -----Original Message----- From: Joseph Salowey <[email protected]> Sent: Sunday, July 19, 2026 1:31 PM To: <[email protected]> <[email protected]> Cc: [email protected]; tls-chairs <[email protected]> Subject: [TLS] MLKEM Consensus Call (was WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)) During this last call we received responses from a large number of people on both sides of the issue, many were from first time participants, which was probably due to the extensive social media coverage. The primary objection discussed extensively during the call concerned the relative strength of pure versus hybrid approaches. Fundamentally, this is a judgement call people have to make for themselves, and the chair’s role is not to just decide for the WG b=t rather to take the sense of the WG. The chairs ultimately bear the burden of how to weigh those responses against those of long-time WG participants with demonstrated expertise. By pure numbers, more people want to progress the document than not, but this alone does not constitute rough consensus. However, if we look at pre-existing WG participants or people with demonstrated expertise, roughly 7/10 WG participants favor advancing the document, which shows rough consensus to move the document forward. Even though there is rough consensus to move forward we feel several issues raised during the last call need to be addressed. Some of the issues below have text proposals that we think are appropriate given the list discussions, we will accept feedback on them, but we do not intend to make significant changes since these issues have already had a fair amount of discussion 1. Emphasize the status of the document Currently the pure ML-KEM algorithm is recommended “N” in t=e IANA registry and is a non-standards-track informational document while X25519MLKEM768 is marked as recommended “Y” and is defined =n a standards-track document. While this indicates the preference for the hybrid approach, it was pointed out that the meaning of the “N =80 value may not be obvious to readers unfamiliar with the IETF process. Based on the discussion the following will be added to the IANA considerations section, which the IESG approved for pure ML-DSA, to save readers following existing links in the document to understand the meaning on N and to further addresses some hybrid/pure approach concerns: As defined in Section 3 of [RFC9847], the value N indicates That the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism. This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an item marked as "N" on the basis of the item having limited applicability or usage constraints 2. Randomness requirements Jacob Appelbaum raised the issue that m random input value is provided directly to the ML-KEM.Encaps() and encrypted and sent to the TLS Client. This means that an attacker who can use raw random output to determine the PRNG state can use a connection with the server to attempt to derive the server's PRNG state and attack other connections. This issue pertains to the ML-KEM algorithm itself and is not unique to TLS. The NIST document currently does require a secure PRNG defined in NIST SP 800-90A-C and RFC 9846 discusses PRNGs in Appendix C. Any text added to address this point would need to be included both in this document and the ECDHE-MLKEM document. Text to go into Section 4.2, after the existing "MUST NOT reuse randomness" line: “During encapsulation, ML-KEM encrypts m, drawn from a random bit generator, so the peer holding the decapsulation key recovers m exactly. Any information that m provides about other outputs of the generator is therefore available to that peer.” And the following text for Section 5 (security considerations): “The disclosure of raw random number generator (PRNG) output in TLS and other protocols can be used in an attack to compromise the state of an insecure RNG as described in [DUALEC-TLS]. The m value in ML-KEM is an additional place where raw RNG output is disclosed to an active attacker. Because the m value in ML-KEM is randomly generated and transmitted to the client, it is important to follow the PRNG guidance in [FIPS203] and [RFC9846]. Implementers MAY choose to implement mechanisms from [RFC8937] for additional protection across sessions." [DUALECTLS] - https://www.usenix.org/system/files/conference/usenixsecurity=4/sec14-paper-checkoway.pdf Similar text will also go into the ECDHE-MLKEM document. 3. Document Track & Stream The document is currently in the RFC stream on the non-standards Informational track. Some have argued for the ISE stream so that the document does not reflect IETF consensus or the document be included on the experimental track. Both of these approaches will result in the publication of an RFC which is the same result as the current path to the average RFC consumer. We believe we have consensus to publish this as an informational working group document Joe On Wed, Jun 24, 2026 at 8:00 AM Joseph Salowey via Datatracker <[email protected]> wrote: > > This message initiates a new Working Group Last Call for > draft-ietf-tls-m=kem[1], which defines standalone ML-KEM key establishment > for TLS 1.3. The=main question before the working group is: "Should the > working group publi=h a document specifying stand alone ML-KEM?". If there is > rough consensus =hen we will push to refine and publish the document; > otherwise, we will st=p discussing the draft and not progress it. Please > respond to this call in=icating whether you support publishing a document > specifying a stand alone=ML-KEM. Please refrain from further discussion on > this topic as most argum=nts have been discussed multiple times. > > Why are we holding this consensus call now? > > Significant developments have occurred both within this document and in t=e > broader TLS ecosystem to address the concerns raised in the last WGLC. > T=erefore, the third consensus call is warranted. We ask the working group t= > consider document publication in light of these recent changes: > > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separat= > consensus call, the WG agreed to promote the X25519MLKEM768 hybrid group =o > Recommended: Y in the IANA registry. Consequently, the IANA registry wil= > reflect a clear community preference for a hybrid because Recommended: Y > =learly indicates this while the standalone ML-KEM groups defined in this > d=aft remain Recommended: N. The updated security considerations in [1] > refe=ence the IANA registry to emphasize this preference. > > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recentl= > reached consensus to explicitly prohibit key share reuse across connectio=s > in TLS 1.3. The new text changes the guidance from SHOULD NOT to a stric= > MUST NOT. This resolves the concerns regarding static key reuse and its > a=sociated privacy and forward-secrecy risks for ML-KEM. > > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid =EM > 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 > =f the components is compromised. > > - Liaisons: We received liaison statements from multiple SDOs including > =-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the > publi=ation of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to > provid= a stable normative reference. > > Please note that a third-party IPR disclosure exists [5] against this > doc=ment regarding patents related to the underlying ML-KEM algorithm. This > IP= declaration has not changed since the last WGLC. As a reminder, per BCP > 7=, the IETF takes no stance on the validity of patent claims, and the > worki=g 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 > Co=duct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback > profess=onal, 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-ie=f-tl > s-mlkem _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
