Is FIPS 204 or any existing literatures explaining or even experimentally showing how serious side-chanel attacks can be led from using a fully deterministic signature algorithm?
Guilin 发件人：Jack Grigg <[email protected]<mailto:[email protected]>> 收件人：TLS List <[email protected]<mailto:[email protected]>> 时 间：2026-04-10 04:45:44 主 题：[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3 I have read the document. I note in particular that it explicitly marks all three ML-DSA signature schemes as "Recommended: N"; I agree that they should not be "Recommended: Y" at this time. On Thu, Apr 9, 2026 at 10:25 PM Rob Sayre <[email protected]<mailto:[email protected]>> wrote: Hi, I think this first point is right. It sure seems like you meant -65. 1. Typo in Table 1: id-ML-DSA-64 should be id-ML-DSA-65 The row for mldsa65(0x0905) lists the Certificate AlgorithmIdentifier as id-ML-DSA-64. It should be id-ML-DSA-65. The OID (2.16.840.1.101.3.4.3.18) is correct for ML-DSA-65, so it's just the name that's wrong — but in a normative table that's the kind of thing that causes implementors to second-guess themselves or file errata. I agree that this is a material typo. I confirmed that [0] (referenced by Section 3.1) lists the registered OID name as id-ml-dsa-65 (it also lists all three in lowercase, but IDK if that matters). This is just a grammar bug: 2. Missing article in Section 3.2 the client MUST treat this a verification failure Should be "treat this as a verification failure." That tracks in other languages, but not in English. I agree, and that it would be helpful to fix this given that it occurs in a conformance requirement. On Thu, Apr 9, 2026 at 11:48 PM Muhammad Usama Sardar <[email protected]<mailto:[email protected]>> wrote: # Security considerations FWIW: the security considerations are insufficient. Security considerations simply refer to FIPS, Sec. 3.4 [1], but I believe we should at the very least forbid deterministic signing with a MUST NOT, because deterministic signing may leave the door open for side-channel attacks and fault injection attacks. The threat models of prominent hardware vendors like Intel TDX and AMD SEV-SNP exclude side-channels. So until something changes, deterministic signing should be forbidden. FIPS 204 Section 3.4 says: > 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. I believe this accurately reflects the security considerations that would otherwise be stated in this document, and I don't think a MUST NOT is necessary here. # Guidance On 09.04.26 22:13, Stephen Farrell wrote: As you might expect, I do not think this should be published at this time without there being guidance as to usage. From my POV the same goes for any RFC for any newish pure PQ. Unsurprisingly, I share this opinion. Everything I have said about introduction and motivation for pure ML-KEM draft applies to this draft as well. I disagree with this opinion, and agree with Viktor. --- Assuming that the material typos will be fixed during final editorial review, I support publication as an RFC. Cheers, Jack [0] https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-13#name-identifiers [1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls12-frozen-08
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
