I don't share that conclusion. I agree with Bas that the FIPS 204 text is fine.I am struggling to see your logic here. You agree with my hypothesis but then not the conclusion? I don't see anything in between the hypothesis and conclusion. So would you mind elaborate a little bit to help me follow your reasoning, please? In particular, say you are an implementer used to reading IETF documents and not NIST documents. Security considerations being offloaded to NIST document is an additional burden for you. But let's put that aside. For your implementation, would you interpret that text as SHOULD NOT or MUST NOT in IETF sense? How would you resolve this ambiguity? I don't think it's ambiguous. I just don't think there is necessarily a 1:1 mapping to IETF language. And I believe this ambiguity has significant high-stakes impact. Say you manage to resolve it as SHOULD NOT: All confidential computing solutions are /almost exclusively/ based on TLS protocol. Would you let attacks like BadRAM, TEE.fail and wiretap.fail continue to be exploited?I don't understand what you're talking about here at all. The attacks you mentionare attacks on TEEs directly and are problems irregardless of how the TLS binding works.
I don't understand as well. These are real and well-documented limitations of commodity TEE hardware - but I think they lead to the wrong conclusion here. IETF standards impose implementation restrictions when there is a clear, demonstrated attack that the restriction concretely prevents. That bar has not been met here. What has been presented is a threat model observation - that TEEs have limitations against physical and privileged attackers - without a concrete attack path showing how deterministic ML-DSA signing in TLS enables key recovery in a way that randomized signing would prevent. Disallowing deterministic mode is restricting a provably secure signing mode (MLDSA is different than ECDSA). This doesn't seem to be a good practice, as it limits implementation flexibility, constrains deployment in environments where deterministic signing is operationally important, and does so without a security benefit that can be articulated concretely.
To add one further technical point on the side-channel question: mitigating physical side-channel attacks requires silicon-level countermeasures - active shielding, voltage and frequency sensors, balanced circuit design - that are architecturally absent from commodity CPUs. This is precisely why hardware vendors including Intel TDX and AMD SEV-SNP explicitly exclude side-channel attacks from their threat models. It is not a gap that can be closed at the software layer, regardless of whether signing is randomized or deterministic. A software-level protocol requirement cannot compensate for the absence of physical silicon structures. So, if side-channel exploitation of signing operations requires attacker capabilities that commodity hardware cannot defend against at any layer, then mandating randomized signing at the protocol level provides no meaningful additional protection.
Personally, I'm opposed to disallowing deterministic signing in ML-DSA in this case. But if one believes that mode is not good for a use case, it is not forced to deploy it.
- Kris
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
