Overall, though this is important to finalize, I found this document a little too loose to be completely ready. That said, none of these are deal-breakers, even the one where I disagree with the choice made in the document.
Section 3.1 says this: > For the purpose of signalling support for signatures on certificates as per > Section 4.2.3 of [RFC8446], these values indicate support for signing using > the given AlgorithmIdentifier shown in Table 1 as defined in [MLDSACERTS]. The referenced section in RFC 8446 mentions TWO extensions. It would seem like this text refers to signature_algorithms_cert, not signature_algorithms. That needs to be clear as this is an important point. Section 3.2 says: > When one of those SignatureScheme values is used in a CertificateVerify > message, then the signature MUST be computed and verified as specified in > Section 4.4.3 of [RFC8446], and the corresponding end-entity certificate MUST > use the corresponding AlgorithmIdentifier from Table 1. Presumably the MLDSA specification has something to say about the verification of signatures here as well. Algorithm 3, perhaps? It also says: > If the signature or public key is of the wrong length, the client MUST treat > this a verification failure, and thus terminate the handshake with > decrypt_error alert. How does one determine what the right lengths are? Would it hurt to provide citations? Section 3.3 says: > The schemes defined in this document MUST NOT be used in TLS 1.2 [RFC5246] or > earlier versions. Given where we stand, I don't agree with this decision. Make of that what you will, but I don't think that observing this MUST NOT is going to get anyone into trouble. Finally, the reference to the different algorithms/parameter sets in FIPS204 are a little loose. Given that the Pre-Hash ML-DSA versions exist and ARE cited very precisely, it might be worth being a little more direct about the way in which the intended parameter sets are referenced. Citing Section 4 and Table 1 would be more than sufficient. Nits: Title Case for Section Titles is Customary. In Section 4, the citations of appendices of TLS 1.3 could be better constructed (so they link to those sections, perhaps; see https://github.com/cabo/kramdown-rfc/wiki/Syntax#-syntax-links and {{<...}}. On Fri, Apr 10, 2026, at 05:30, Sean Turner wrote: > This is the working group last call for Use of ML-DSA in TLS 1.3. > Please review draft-ietf-tls-mldsa [1] and reply to this thread > indicating if you think it is ready for publication or not. If you do > not think it is ready please indicate why. This call will end on April > 23, 2026. > > REMINDER: If you have not done so recently, review the TLS WG's Mail > List Procedures; see [2]. > > The Chairs, > Deirdre, Joe, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ > [2] https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/ > > _______________________________________________ > 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]
