Does https://github.com/tlswg/tls-mldsa/pull/39 (already posted elsewhere in the thread) address your thoughts? It: - Mentions the specific security requirement TLS has for signature schemes and matches it to the corresponding section in FIPS 204 - Mentions hedged signatures is one of the points in those sections
> In case of "simply apply", they more likely ignore security considerations/issues at all, without reading the references. Honestly, I think think ignoring most of these is actually correct here, *for the audience of this document*. The audience for those security considerations isn't the *TLS* implementor. It's the *ML-DSA* implementor. By the time, you get to implementing TLS, knowing that, say, you should not use floating point arithmetic to implement ML-DSA (FIPS 204 §3.6.4: "Implementations of ML-DSA shall not use floating-point arithmetic, as rounding errors in floating point operations may lead to incorrect results in some cases.") isn't all that useful because you're not making that decision anymore. It's just like how your SHA-256 implementation had better pass SHA-256 test vectors, but we're not going to mention that in RFC 8446. David On Fri, Jun 12, 2026 at 9:25 PM Wang Guilin <[email protected]> wrote: > > > Sometimes the underlying spec fails to specify something. Then we need > to say something and all the above awkwardness is unavoidable. But we do > everyone a favor if we limit ourselves to only those. If TLS documents > habitually restate security considerations that the underlying primitives > already stated, readers will gloss over our security considerations and > assume the primitive implementor (who did not read the TLS-layer spec) say > the corresponding lower-level text. But if we only do this in the rarer > cases that the lower-level text actually missed something, readers will > know there was actually some undocumented consideration and take the time > to check. > > Good ponits! > > Is it possible to briefly mention the main security issues/requirements > considered in existing specifications apply? Definitely not restate the > same issues, but a little more info than "the security considerations of > [a], [b] and [c] apply". > > This tells the readers/implementors what the main security issues involved > here, and thsese issues have been considered/evaluated by the authors and > the working group. They may need to pay some attention on these issues. > > In case of "simply apply", they more likely ignore security > considerations/issues at all, without reading the references. > > Also, as this specification is specific to use ML-DSA in TLS, so it is > valuable to stress/repeat the security properties that ML-DSA is supposed > to have for its useage in this sepecification. It is possible that FIPS 204 > states 5 security properties, but this spec may only require 1 or 2. > > About hedged vs deterministic variants, it could be helpful to mention a > sentence. For example, both are supported in this spec, though a more > conservative implementation MAY choose the hedged variant. > > Guilin > > *发件人：*David Benjamin <[email protected]> > *收件人：*Ilari Liusvaara <[email protected]> > *抄 送：* <[email protected]> > *时 间：*2026-06-11 23:56:55 > *主 题：*[TLS] Re: Genart last call review of draft-ietf-tls-mldsa-03 > > > Implementations should not rely on the protcool layer for security. > > And protocol layer should not rely on implementation internals. > > I agree with this. Just as we don't rely on the protocol layer to secure > the implementation of the underlying algorithm, we also don't need to rely > on the protocol layer to specify the underlying algorithm. > > Practically speaking, the TLS layer does not implement ML-DSA directly. It > calls into the ML-DSA implementation. If the ML-DSA spec failed to capture > this, by the time the TLS implementor goes to look at the TLS spec, we're a > few layers past ML-DSA. Decisions about hedged vs deterministic have > probably already been made. > > Happily, FIPS 204 talks about this *already* in section 3.4: > > > This document also permits a fully deterministic variant of the signing > procedure in case the signer has no access to a fresh source of randomness > at signing time. However, the lack of randomness in the deterministic > variant makes the risk of side-channel attacks (particularly fault attacks) > more difficult to mitigate. Therefore, this variant *should not* be used on > platforms where side-channel attacks are a concern and where they cannot be > otherwise mitigated. > > Footnote: As this is a NIST document, it uses NIST's definition of > "should", but it's comparable to ours. They define it as "Used to indicate > a strong recommendation but not a requirement of this standard. Ignoring > the recommendation could lead to undesirable results." > > I don't see any need to override this. It both describes why the hedged > variant is preferred, and says that you should not use it when side-channel > attacks are a concern. > > Are there cases where the application needs to heed that advice? Sure. The > FIPS 204 guidance is perfectly sufficient to capture that. Are there cases > where the protocol input happens to be random enough anyway? Maybe. Is TLS > one of these? I mean there's some entropy anyway, but then it looks > slightly different and is sent over the wire, etc. It is not worth > loosening NIST's guidance on this one. > > Don't reinvent the wheel when we have a solid one already. Every > requirement we add to a document like this is an extra bit of text that > *everyone* who comes after us must forever read and consider. If there > was already text to the *exact same effect* in force, we can cite it and > move in. > > Sometimes the underlying spec fails to specify something. Then we need to > say something and all the above awkwardness is unavoidable. But we do > everyone a favor if we limit ourselves to only those. If TLS documents > habitually restate security considerations that the underlying primitives > already stated, readers will gloss over our security considerations and > assume the primitive implementor (who did not read the TLS-layer spec) say > the corresponding lower-level text. But if we only do this in the rarer > cases that the lower-level text actually missed something, readers will > know there was actually some undocumented consideration and take the time > to check. > > > On Wed, Jun 10, 2026 at 9:44 AM Ilari Liusvaara <[email protected]> > wrote: > >> 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] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
