[TLS] MLKEM Consensus Call (was WG Last Call: draft-ietf-t ls-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 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]