It is notable that, while this text draws a clear distinction between pre-existing WG participants and others (ignoring the substance of the debate since then), the presence of a double-digit number of identified intelligence agency operatives from the NSA, GCHQ, and CSE [1], the resulting conflict of interest, and their uniform voting behavior remain completely unaddressed.
Kind regards, Ken Kubota ____________________________________________________ Ken Kubota https://doi.org/10.4444/100 [1] https://mailarchive.ietf.org/arch/msg/tls/lnSPh3Wr6vgdjivHGj1mxCun3Rs/ > Am 19.07.2026 um 13:31 schrieb Joseph Salowey <[email protected]>: > > 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 but > 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 the IANA > registry and is a non-standards-track informational document while > X25519MLKEM768 is marked as recommended “Y” and is defined in a > standards-track document. While this indicates the preference for the > hybrid approach, it was pointed out that the meaning of the “N” 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/usenixsecurity14/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-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]
