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 to [email protected]
