Skip to main content

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