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

Dear Joseph and all,

I thought for a while how to answer this specific issue raised in your
mail, regarding taking into account the past participation.

Admittedly, this is my first direct involvement with IETF, so I understand
that my views were considered to be of a lesser value than those who
participated in previous discussions, independent of the amount of
expertise I may (or may not, you know, being stuck in the ivory tower has
its prices) have gathered since my first academic paper on cryptography
(which surprisingly analyzed the security of an NSA cipher that was just
declassified back then, namely the Skipjack cipher that was part of the
Clipper chip). I know that many standardization bodies wish to have more
academics involved in the different processes, and disregarding one's
expertise, certainly makes me feel welcomed into the process here and
encourages me to contribute to future IETF discussions on TLS.

During the discussion, some mistakes and misconceptions were mentioned, and
I've checked, I was the only one that caught them (or bothered to respond
to them), like the claims that the good ol' GSM ciphers were not backdoored
(which is factually incorrect - from the clear intentional weakening of
A5/2 to the planned backdoor in GEA1). There were some other issues that I
wanted to answer in a very detailed way, but as the incentives for
academics are built in such a way that any involvement with standardization
bodies is mostly a hobby for us (please read this as - we are not paid to
do that, and actually, this usually deters us from doing the tasks we do
get paid to do), I did not get to it so far. Of course, I now humbly
understand that this input is less worthy, as I haven't participated in
past discussions, which certainly encourages me to find other hobbies, like
collecting and training homing pigeons for implementing RFC 1149.

An example for such a discussion is about applying hashing to the output of
a PRNG. Some people claimed that this does not add security whereas some
have claimed that it does. For me this is a weird discussion, because the
view that hashing the output of the PRNG does not add security is not
technically accurate: (a) it is counterintuitive (the more you add
nonlinearity, you are usually the better, assuming of course, you avoid
some corner cases) (b) not supported by any real life experience (consider
the Linux PRNG that hashes the entropy poll on the way to the output, or
many QKD devices that hash the quantum key, just in case), and (c) actually
wrong (hashing the output of DUAL-EC-DBRG would have prevented some of the
resulting attacks). At the same time, my "wild" technical claims and views
should be given less weight in the discussion, as I haven't contributed
enough to previous IETF discussions.

I also have some thoughts about whether we should trust people who were
involved in the BULLRUN program for subverting cryptographic standards, to
make new standards, even if they are no longer employed by the same
organizations, but obviously only people with 20 years worthy of IETF
discussion (e.g., under that said program) should probably be involved in
the consensus regarding that issue. By the way, according to the publicly
mentioned policy by Joseph, the views of an NSA employee who tricked the
IETF into adopting DUAL EC DBRG should be have a LARGER weight than those
of a person who never tried to trick the IETF to adopt a faulty backdoored
algorithm, just because he never participated in IETF discussion. This is a
very logical policy, consistent with the way trust and security are built
in the ICT world, and obviously, many people outside the IETF will gladly
agree with this policy.

Just a tiny question, which you can disregard happily, as I am a recent
newcomer to this mailing list - was a similar policy applied in the
previous calls? I mean, I've looked in the counting of the previous call
for consensus, and I haven't seen next to each person whether the view was
weighted more or less according to the XP points the person collected in
past IETF posts.

[And to clarify:
1. I am not claiming that anyone on this mailing list at the moment, at any
role or capacity, has been involved in BULLRUN/subverted cryptographic
standards/forgot to implement RFC 3514.
2. I am not appealing the decision to declare a rough consensus, just
voicing my view on the above mentioned policy.
]

On Mon, Jul 20, 2026 at 10:52 PM Joseph Salowey <[email protected]> wrote:

> 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]