I think it is best not to add the suggested text. The signer can only rely on its own TLS random value, and while the hedged randomness is often produced and kept inside a certified hardware security module, the TLS randomness is not.
Cheers, John Preuß Mattson From: Bas Westerbaan <[email protected]> Date: Thursday, 21 May 2026 at 11:09 To: Ilari Liusvaara <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: [Last-Call] Last Call comment on draft-ietf-tls-mldsa-03: Security Considerations On Thu, May 21, 2026 at 9:43 AM Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Thu, May 21, 2026 at 03:20:32PM +0800, Blue Dog wrote: > > The concrete change I still think is worth considering is the narrower > implementer-facing guidance on deterministic versus hedged ML-DSA signing. > That guidance seems TLS-relevant because the signer behavior is not visible > on the wire, and implementers may otherwise treat the choice as a library > default without noticing the operational/security trade-off for long-lived > authentication keys. For TLS, deterministic versus hedged ML-DSA does not matter[1]. However, given that at least three people have commented about this, I think that maybe the specification should mention something about it. This is a good suggestion. Thanks Ilari. https://github.com/tlswg/tls-mldsa/pull/36 [1] The randomizer only appears together with the message hash, so it only affects things if the same message is signed twice, which TLS never does (as the input includes things like client and server randoms). -Ilari _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
