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]
