Hello, I reviewed draft-ietf-tls-mldsa-03 with a focus on implementer-facing security guidance. I am not objecting to publication, but I think the document would benefit from a short addition to the Security Considerations.
The draft currently references FIPS 204 and specifies the use of ML-DSA.Sign and ML-DSA.Verify with an empty FIPS 204 context parameter. However, the document does not appear to surface the operational choice between deterministic and hedged signing. Since TLS implementations already depend on high-quality randomness, and since side-channel and fault-injection considerations are particularly relevant for long-lived authentication keys, I suggest making the expected signing behavior more explicit. Possible text: Implementations that generate ML-DSA signatures for TLS authentication SHOULD use the hedged signing variant when suitable randomness is available, as described in FIPS 204. Implementations that use deterministic signing need to consider the increased sensitivity of repeated signing operations under side-channel or fault-injection conditions, particularly for long-lived private authentication keys. This document does not define a TLS protocol signal for the signing variant; this is an implementation and deployment consideration for the endpoint generating the signature. This would avoid implementers treating the signing variant as an arbitrary library default, and would make the TLS-specific deployment expectation clearer without changing the wire protocol or the registered SignatureScheme values. I would also suggest one sentence noting that local policy may restrict the use of standalone ML-DSA authentication in deployments that require hybrid authentication during the transition period. That would keep the document clear that it defines code points and negotiation behavior, while deployment policy remains a separate decision. Best regards, Songbo Bu
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
