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

Hi Viktor,

On 7/12/26 17:07, Viktor Dukhovni wrote:
> On Sun, Jul 12, 2026 at 04:02:55PM +0200, David Stainton wrote:
> 
>> There may be better designs but they will only slow down deployment.
>> The best course of action is restoring the hash over m.
> 
> The hash over "m" is not a matter for TLS to dictate. 

The tls working group can easily make a statement in any draft related 
to ML-KEM about it if it wants to achieve consensus.

> It lives
> inside the ML-KEM algorithm black box.

Large-scale adversaries love this kind of clean separation of concern 
where the upper layer just accepts any issues with the lower layer. It 
makes sense but it also means that it is a way to exploit different 
assumptions at different layers.

> Many TLS stacks that
> are polymorphic over various KEMs don't even know which KEMs
> are ML-KEM and which aren't.  The X25519MLKEM768 hybrid isn't
> ML-KEM, it is just another black box.
> 

That isn't correct but it slightly depends on what you mean.

For example recovering `m` in the X25519MLKEM768 case is 
straightforward. Noteworthy is that if the X25519 keypair is generated 
after `m` is sampled, the adversary is able to predict the X25519 
keypair. I trust that this is not in dispute.

> Whether `m` comes directly from a compromised RNG, or from a whitened
> RNG isn't something TLS can detect and has no effect on
> interoperability. 

That is why IETF endorsing the Kyber hashing strategy is a fine plan. No 
one will notice except users of the covert channel and those worried 
about ~300-1500 cycles.

> Nothing productive, will happen in typical
> implementations if TLS suggests whitening the RNG used with ML-KEM.
> 

It closes the covert channel.

> I for one have no intention to implement that. 

With respect, that is your security posture, I think that is important 
for people to know. Is there any evidence that would convince you to 
change your mind, and if so, what is the standard of evidence that would 
move you?

> TLS is not supplying the
> ML-KEM encapsulation step with its entropy, that's an internal detail of
> the algorithm, and I don't expect to change that because of security
> theatre motivated by this thread.
> 

It depends on the implementation, of course. It isn't security theater 
in any case. Some systems will be exploitable with this class of 
attacks, and some will not. IETF should make the issues clear, and issue 
clear guidance for people who want defense-in-depth.

> Any language to that effect will I predict be broadly ignored.
> 

The IETF doesn't have protocol police. We can survey your prediction 
later. Currently, I see only a few implementations that hash `m` and I 
suspect it will grow proportional to the humility of the developers in 
question. The people designing their own RNG are probably going to feel 
like that hash is a lot less important than people who can't 
meaningfully inspect their rng or otherwise do anything but hope that 
the cryptography actually protects us from _all_ the known possible 
problems that might come along.

> If someone wants to issue new code points, OIDs, ... test vectors,
> for a new ML-KEM' that always hashes `m`, good luck with that...

Thankfully that isn't needed at all. There are other options but 
restoring Kyber's hash is the easiest and fastest solution that closes 
the covert channel.

Kind regards,
Jacob Appelbaum

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