> 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]<mailto:[email protected]>> 收件人：Ilari Liusvaara <[email protected]<mailto:[email protected]>> 抄 送： <[email protected]<mailto:[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]<mailto:[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]<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]
