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

Hi,


> 19.07.2026 Joseph Salowey <[email protected]>:

(..)

> 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.”


This is Ok. Note that here the term "random bit generator" (RBG) is used.
Of course we wouldn't expect a RBG to give any information about other
outputs or the state, since it is a RBG (see below), but it may as well be
mentioned.


Obviously the mentioned reveal also applies to hybrids such as
X25519MLKEM768 as well ( the hybrid key derivation is not a black box to
the recipient. )


>

> 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


Here the text talks of a "raw random number generator" which it
abbreviates refers
to as PRNG ("P" is for pseudo.). This is not a well defined term, and I
agree with Quynh that it is better adjusted as  “The disclosure of the
output(s) of an insecure random number generator (RNG) when used in TLS and
other protocols can be used in an attack to compromise the state of the
insecure RNG itself as described in [DUALEC-TLS]."


> 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


The term "raw RNG" here seems ok -- it is undefined but I guess it means
"insecure RNG."


> 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."


Here, the term PRNG makes a comeback. Perhaps change it to RNG for
consistency. FIPS 203 does not offer PRNG guidance, but RBG guidance. An
RBG may or may not be deterministic.


To recap: RNG is an incredibly vague term as it implies no clearly defined
security properties -- but this is what the IETF has been using. As noted,
FIPS land talks of RBGs (and defines what they are), as does a part of the
CC land. CC also uses the AIS 20/31 terminology and classification, in
which RNG is essentially a catch-all, and protection profiles impose
additional, more detailed requirements for entropy generation and
post-processing.


FIPS 203 actually asks for an RBG, which implies:

- seeding from a sufficient amount of entropy, and also

- cryptographically secure post-processing where any number of output bits
do not offer an advantage in predicting or determining unrevealed output
bits, assuming cryptographic security of SHA2 or AES, etc.


The more casual mathematical term PRNG implies neither cryptographic
security nor sufficient entropy seeding — simply determinism. Often PRNGs
are distinguished from RNGs specifically because they do not have
sufficient seeding.


American standard terminology has a class of RBGs called DRBGs
(Deterministic Random Bit Generators). Because DRBGs are deteministic,
technically they are PRNGs, but they are also RBGs -- when instantiated,
the standards (and testing labs) require adequate seeding and an
appropriate level of security in post-processing components (for example, a
DRBG based on AES-128 is not sufficient for a 256-bit security level).

There is also the "CRA land" in Europe, and ECCG & ENISA is searching for a
suitable compromise for entropy in lower-assurance products (non-CC.). But
at this point acceptable DRBGs are listed in the ACM (they all have
cryptographically secure post-processing). It has been of course proposed
that, e.g., Linux Random would be considered ok as an entropy source for
consumer products, for obvious practical reasons.


Best Regards,
-markku

Dr. Markku-Juhani O. Saarinen <[email protected]>


On Sun, Jul 19, 2026 at 3:58 PM Quynh Dang <[email protected]> wrote:

> Hi Joe and Sean,
>
> This sentence: “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]. " would need to be
> edited as below to make it clear to the readers.
>
> “The disclosure of the output(s) of an insecure random number generator
> (RNG) when used in TLS
> and other protocols can be used in an attack to compromise the state
> of the insecure RNG itself as described in [DUALEC-TLS]."
>
> Regards,
> Quynh.
>
> On Sun, Jul 19, 2026 at 8:21 AM Ken Kubota <[email protected]> wrote:
>
>> 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.
>>
>> Kind regards,
>>
>> Ken Kubota
>>
>> ____________________________________________________
>>
>> Ken Kubota
>> https://doi.org/10.4444/100
>>
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/tls/lnSPh3Wr6vgdjivHGj1mxCun3Rs/
>>
>>
>>
>> > Am 19.07.2026 um 13:31 schrieb Joseph Salowey <[email protected]>:
>> >
>> > 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]
>>
>> _______________________________________________
>> 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]
>

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