[TLS] Re: MLKEM Consensus Call (was WG Last Call: draft- ietf-tls-mlkem-08 (Ends 2026-07-08))

Bernstein has mentioned off-list that excluding all but "pre-existing WG participants" [1] runs counter to IETF principles. [2]

An IETF document explicitly states: "IETF participation is free and open to all interested individuals. [...] Decision-making requires achieving broad consensus via these public processes." [3]

My comment stated: "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." [4]

I would also like to request the participant list/table, as well as clarification on how the six votes cast by the NSA and the votes cast by other intelligence services -- which aligned uniformly -- were addressed. There is clearly a conflict of interest [5] as outlined in RFC 7282 (On Consensus and Humming in the IETF) Section 7 and detailed in point 3 of [6].

Concerning Andrew's appeal and the escalation ladder [7], it should also be noted that the first step may involve discussing the matter with "the Working Group as a whole" (RFC 2026 Section 6.5.1 [8]).

As the SSH mailing list is also plagued by issues of conflict of interest dating back to 2024 [9], and inadequate reactions such as framing a conflict of interest as an ad hominem attack [10], I am crossposting to this list.

My original message detailing the involvement of eleven intelligence service operatives from the NSA and other agencies was:
    https://mailarchive.ietf.org/arch/msg/tls/lnSPh3Wr6vgdjivHGj1mxCun3Rs/
The warning issued, and my still-unanswered post, were:
    https://mailarchive.ietf.org/arch/msg/tls/ZEmoMBkoOu9uLeZe0zcettVy5qY/

Kind regards,

Ken Kubota

____________________________________________________

Ken Kubota
https://doi.org/10.4444/100



[1] https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/

[2] https://microblog.cr.yp.to
"2026.07.19 13:01:20: Can we get the IETF TLS WG chairs to help out with the U.S. elections? Allow votes only from pre-existing landowners plus the list of people who the chairs declare have demonstrated enough expertise to vote? Also, make sure to hide that list: https://web.archive.org/web/20260719121145/https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/

2026.07.19 12:52:02: "IETF participation is free and open to all interested individuals. ... Decision-making requires achieving broad consensus via these public processes." (https://web.archive.org/web/20260703153542/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/). Reality: pay-to-play; NSA casts 6 votes; NSA pays its vendors to vote; chairs throw away _your_ vote.

2026.07.19 12:23:17: IETF TLS WG chairs have arrogated to themselves the power to disenfranchise all except "pre-existing WG participants" + people who the chairs say have "demonstrated expertise": https://web.archive.org/web/20260719121145/https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/ They say: gives 7/10 in favor; "rough consensus". RFC will claim "consensus".

2026.07.09 19:12:08: Wait, I undercounted: NSA cast _six_ votes (Mike Jenkins, Nicholas Gajcowski, William Layton, Morgan Stern, Peter Yee from non-NSA address, Mark Motley from non-NSA address). Looking beyond NSA: DoD's Ann Krieger; DoD lifer Major Mike StJohns. Three GCHQ, two CSE, one partridge.

2026.07.09 16:40:45: IETF TLS WG chairs have closed the vote, and say they'll go through https://mailarchive.ietf.org/arch/browse/tls/ "to see what the consensus is". Consensus? Each side received more than 80 votes on list: e.g., 7 positive votes from DoD, 4 from Cisco, etc. (5 on each side didn't give full real names.)"

[3] https://web.archive.org/web/20260703153542/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
"IETF processes and procedures are particularly well-suited to mitigate competition law risks. IETF participation is free and open to all interested individuals. Participants engage in their individual capacity, not as company representatives. A wide range of perspectives is represented, reflecting interests from multiple industry sectors, academia, government and non-governmental organizations (NGOs), from around the globe. IETF procedural rules, which include robust appeal options, are well-documented in public materials, and rigorously followed. IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes. IETF’s disclosure-focused intellectual property rights policies carefully and transparently balance the interests of standards contributors and standards adopters. Fundamentally, “IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user.”[RFC 7154]"

[4] https://mailarchive.ietf.org/arch/msg/tls/xEZajmEJ3qgKFlnNTVR2lp2nkDU/

[5] https://mailarchive.ietf.org/arch/msg/tls/fTy_xd7SKqxo6ZExzSDA8SRuT_8/

[6] https://mailarchive.ietf.org/arch/msg/tls/ZEmoMBkoOu9uLeZe0zcettVy5qY/

[7] https://mailarchive.ietf.org/arch/msg/tls/ByLJ7Kf1EbP2fESF5R4KRhkKPsE/

[8] https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.1

[9] https://mailarchive.ietf.org/arch/msg/ssh/zivwujXjdICXl5s48P1gX0LGHCY/

[10] https://mailarchive.ietf.org/arch/msg/ssh/o6VE5SAai2lqJLXzpdRxs1Zdruw/



> Am 19.07.2026 um 15:55 schrieb DA PIEVE Fabiana <[email protected]>:
> 
> 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]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]