Hello Ilari, Bas, John,

Thank you for the clarification, and thank you Bas for opening PR #36.

>From my side, I do not intend to push for a normative requirement on the
signing mode. The point I was trying to raise would be addressed by a short
explanatory note, if the WG thinks such a note is useful, making clear that
TLS does not signal the signing variant and that the TLS signature input
already contains fresh transcript material such as the client and server
random values.

That clarification is narrower and better than the text I originally
suggested. I have no further comment on this point and will follow the PR.

Best regards,

Songbo Bu

On Thu, 21 May 2026 09:23:51 +0000, John Mattsson
[email protected] wrote:

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]
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]

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

Reply via email to