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

The TLS Mailing List Archive is public & available at the following url:

https://mailarchive.ietf.org/arch/browse/tls/

Bulk extracts can also be downloaded with rsync as described here:

https://www.ietf.org/about/open-records/

Best,
Dennis

On 20/07/2026 22:08, Ken Kubota wrote:
> I am writing to clarify the statement in your email regarding the 
> statistic "7/10 WG participants favor advancing the document."
>
> Transparency is a core principle of the IETF.
>
> Please provide the breakdown or data that supports this figure.
>
> Thank you for your assistance.
>
> Kind regards,
>
> Ken Kubota
>
> ____________________________________________________
>
> Ken Kubota
> https://doi.org/10.4444/100
>
>
>
>> Am 20.07.2026 um 21:51 schrieb Joseph Salowey <[email protected]>:
>>
>> As others have mentioned on this thread, a consensus call is not a
>> vote. We used public responses to get a sense of where the mailing
>> list participants are leaning. In this case, we saw many participants
>> who had not participated in the previous calls or on the TLS list in
>> general.  The chairs have the remit to judge consensus based on input
>> such as taking into account the level of previous participation of the
>> sender.  There is no specific threshold which represents rough
>> consensus. In this case, we judged that the responses show rough
>> consensus to move forward with publishing the document and to address
>> the issues raised during the consensus call.
>>
>> All of the mail used as part of this process is publicly available. We
>> do not intend to release any further detailed analysis including
>> "numbers" or "weights/methods".
>>
>> Thanks,
>>
>> Joe
>>
>>
>> On Sun, Jul 19, 2026 at 6:55 AM DA PIEVE Fabiana
>> <[email protected]> wrote:
>>>
>>> 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 [email protected]

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