[Gen-art] Re: [TLS] Re: Genart last call review of draft-ietf-tls-mldsa-03

[John Mattsson <[e-mail]>]

Thanks Bas,

I misunderstood the role of the client randomness — my mistake. With your explanation of ρ'', I agree that placing equal-quality randomness in rnd and M is equivalent, and that TLS-generated randomness should be good enough.

I still believe the PR's conclusion that hedged signing "does not apply" is too strong, The purpose of hedged signing is to allow the ML-DSA implementation to mitigate side-channel risks by randomizing internal computations, regardless of how it is invoked.  After thinking about it further, I believe the PR overlooks two important considerations.

1. M is known to an attacker, whereas rnd is secret. This distinction is important because a secret rnd makes the internal computation unpredictable, even when the attacker has full knowledge of M.

2. The PR assumes that the TLS stack is the sole caller of ML-DSA.Sign(). If deterministic signing (rnd = 0) is used and the implementation contains side-channel vulnerabilities, an attacker who can submit chosen messages to the ML-DSA.Sign() interface may be able to recover the private key and subsequently impersonate the server or client.

Hedged signing is designed as a primitive-level defense-in-depth mechanism. We shouldn't rely on the protocol layer to secure the implementation of the underlying algorithm.

(I will try to think tomorrow if I have a suggestion for an alternative text for the security consideration)

Cheers,
John Preuß Mattsson

From: Eric Rescorla <[e-mail]>
Date: Tuesday, 9 June 2026 at 21:19
To: Bas Westerbaan <[e-mail]>
Cc: John Mattsson <[e-mail]>; [e-mail] <[e-mail]>;
<[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [TLS] Re: Genart last call review of draft-ietf-tls-mldsa-03



On Tue, Jun 9, 2026 at 12:12 PM Bas Westerbaan <bas=[e-mail]<mailto:[e-mail]>> wrote:
- The idea that the server can use the client random to protect against side-channel attacks is obviously wrong.

Which is not claimed. Client randomness is mentioned as we're also concerned with client authentication.

- The server random and the ML-DSA rnd value are used in different parts of the input and could affect side-channel behavior in different ways.

For those reading along, the only place ML-DSA rnd and the input message M is used, is in the computation of rho'':

rho'' = H(K || rnd || H((tr) || 0 || len(ctx) || ctx || M))

M contains the transcript hash which includes the client/server randomness.

- The server random and the ML-DSA rnd value might be generated by completely different random number generators with different quality. It is not clear that the ML-DSA rnd can be replaced by server random.

This PR should not be merged in its current form. It makes very strong statements ("do not apply") with little motivation. I think more analysis would be needed even to support weaker statements.

The TLS standard requires a good source of randomness. Indeed, its security analysis has several very strong statements (eg. replay protection) which would need to be revisited if we were to put that requirement into question.

I don't have an opinion on ML-DSA, but is strong randomness rather than uniqueness a requirement for replay protection?

-Ekr