IETF Last Call Review of draft-ietf-tls-mldsa-03
review-ietf-tls-mldsa-03-secdir-lc-kaufman-2026-05-28-00
| Request | Review of | draft-ietf-tls-mldsa |
|---|---|---|
| Requested revision | No specific revision (document currently at 03) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-06-01 | |
| Requested | 2026-05-18 | |
| Authors | Tim Hollebeek , Sophie Schmieg , Bas Westerbaan | |
| I-D last updated | 2026-06-01 (Latest revision 2026-05-06) | |
| Completed reviews |
Genart IETF Last Call review of -03
by Joel M. Halpern
Secdir IETF Last Call review of -03 by Charlie Kaufman |
|
| Assignment | Reviewer | Charlie Kaufman |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-tls-mldsa by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/QubgANNbqg-apsqdsZCKOjDmGFY/ | |
| Reviewed revision | 03 | |
| Result | Has nits | |
| Completed | 2026-05-27 |
review-ietf-tls-mldsa-03-secdir-lc-kaufman-2026-05-28-00
Reviewer: Charlie Kaufman Review result: Has nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This short document adds three codepoints to IANA's TLS SignatureScheme namespace for three variants of the new quantum-safe ML-DSA signature algorithm. This should be non-controversial. Three aspects are noteworthy: (1) There are three codes specified for the three recommended key sizes. This differs from our approach to some other algorithms where supported key sizes are unspecified. The old approach has caused us interoperability problems so I believe this approach is an improvement. (2) NIST defined two slightly different forms of each of these signature formats, and this spec only defines code points for one of them as recommended in RFC9881. This seems like the right thing to do. (3) Section 3.3 explicitly says that these algorithms MUST NOT be used in TLS 1.2 or earlier versions. While it's hard to imagine anyone rushing out to support new algorithms in old protocols, I don't see why it is important to disallow them, and if they were to support them it would seem appropriate to use these same code points. Nit: First paragraph of section 3: "as follows as follows" should be "as follows" —Charlie