[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hi Paul,

On 7/13/26 16:54, Paul Wouters wrote:
> On Mon, 13 Jul 2026, Jacob Appelbaum wrote:
> 
>> The tls working group can easily make a statement in any draft 
>> related to ML-KEM about it if it wants to achieve consensus.
> 
> "Just to clarify", if a sentence about RNG is included in the hybrid 
> and pure mlkem drafts, you would then change your view ane be in 
> favour of the pure mlkem draft being published? Or are you going to 
> be against it no matter what is said on the RNG issue?
> 

For the hybrid draft, my concrete request is simple: restore Kyber's
original defense-in-depth construction. That means hashing `m` is a
MUST, and the motivation should say that this destroys hidden structure
in random-generator output, with Dual_EC_DRBG as the historical example.
This is not an entropy argument and we're not making a new cryptographic
construction that requires three more rounds of NIST PQC.

This change is compatible with the IETF making a more conservative
choice than NIST. The draft is not standardizing a FIPS-certified stack,
and there are no protocol police. Some implementations will follow the
guidance and some will not, but the IETF should say the safe thing
clearly. Some will argue that it shouldn't be a MUST and well, that
certainly is a security posture.

For draft-ietf-tls-mlkem-08, I would want at least the same fix. I am
not completely opposed to a non-hybrid ML-KEM document, but I do not
currently support publishing this one as-is.

There are other outstanding concerns besides my `m` concern: the
approved-RBG dependency, the Security Considerations gaps, remote
side-channel/covert-channel interaction, and the question of how the
draft describes standalone ML-KEM's assumptions. Is anyone tracking all
of the outstanding concerns systematically so they can be addressed one
by one? Do you have an authoritative list?

The phrase "pure ML-KEM" is also not my preferred framing. A
non-hybrid ML-KEM draft could be useful if it is descriptive, precise,
and honest about its assumptions and risks. But publishing it as a WG
consensus document without resolving the open technical concerns is a
different matter.

So my answer is: maybe, depending on the text. If the drafts restore
Kyber's hash over `m`, clearly explain why, and address the remaining
Security Considerations issues systematically, I am open to changing my
view. If the proposal is only to add a generic RNG sentence, then no,
that isn't responsive to basically any concerns raised and it certainly
isn't robustly protecting the end user.

Given that WGLC has ended and consensus does not appear clear to me, I
would also like to understand the process question: are you suggesting
that the draft could still be declared to have consensus, or that there
would be another last call after concrete text is proposed? As in, are
you now discussing a hypothetical draft-ietf-tls-mlkem-09?

A generic sentence about the RNG is not sufficient. I am open to finding 
something that is sufficient.

Kind regards,
Jacob Appelbaum

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