On Tue, Jun 09, 2026 at 09:11:54PM +0000, John Mattsson wrote: > Thanks Bas, > > 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.
An implementation is free to always use hedged signing for other reasons. That it does not matter for TLS does not imply that it does not matter for anything else. But it does imply that ML-DSA implementations can ignore TLS, and that TLS implementations can ignore if hedging is done or not. If that is not clear, I think it should be made clear. Genuinely problematic would be requirement or recommendation to use deterministic signing. Or recommendations to use fully random signing. > 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. The computation would still be unpredictable because of the K, which is part of private key. > 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. If implementation is concerned about side-channel vulnerabilities, it can always apply hedging, or some even more heavy countermeasures. And it is not actually chosen messages that are the problem, but submitting the same message many times. Even if one knows the message, one can not predict rhoprimeprime. > 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. Implementations should not rely on the protcool layer for security. And protocol layer should not rely on implementation internals. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
