Use of ML-DSA in TLS 1.3
Internet-Draft draft-tls-westerbaan-mldsa-00
Tim Hollebeek
DigiCert
tim.hollebeek@digicert.com
Sophie Schmieg
Google
sschmieg@google.com
Bas Westerbaan
Cloudflare
bas@cloudflare.com
15 November 2024
ML-DSA
FIPS204
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3.
About This Document
The latest revision of this draft can be found at https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/.
Source for this draft and an issue tracker can be found at https://github.com/bwesterb/tls-mldsa.
Introduction
ML-DSA [FIPS204] is a post-quantum signature schemes standardised by NIST. It is a module-lattice based scheme.
This memo specifies how ML-DSA can be negotiated for authentication in TLS 1.3 via the "signature_algorithms" and "signature_algorithms_cert" extensions.
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
ML-DSA SignatureSchemes Types
As defined in [RFC8446], the SignatureScheme namespace is used for the negotiation of signature scheme for authentication via the "signature_algorithms" and "signature_algorithms_cert" extensions. This document adds three new SignatureSchemes types for the three ML-DSA parameter sets as follows.

enum {
  mldsa44(0x0904),
  mldsa65(0x0905),
  mldsa87(0x0906)
} SignatureScheme;

These correspond to ML-DSA-44, ML-DSA-65, and ML-DSA-87 defined in [FIPS204] respectively. Note that these are the pure versions and should not be confused with prehashed variants such as HashML-DSA-44 also defined in [FIPS204].
Similarly, the context parameter defined in [FIPS204] Algorithm 2/Algorithm 3 MUST be the empty string.
The signature MUST be computed and verified as specified in Section 4.4.3 of [RFC8446].
The corresponding end-entity certificate when negotiated MUST use id-ML-DSA-44, id-ML-DSA-65, id-ML-DSA-87 respectively as defined in [I-D.ietf-lamps-dilithium-certificates].
The schemes defined in this document MUST NOT be used in TLS 1.2 [RFC5246]. A peer that receives ServerKeyExchange or CertificateVerify message in a TLS 1.2 connection with schemes defined in this document MUST abort the connection with an illegal_parameter alert.
Security Considerations
TODO Security
IANA Considerations
This document requests new entries to the TLS SignatureScheme registry, according to the procedures in Section 6 of [TLSIANA].
Value | Description | Recommended | Reference
0x0904 (please) | mldsa44 | N | This document.
0x0905 (please) | mldsa65 | N | This document.
0x0906 (please) | mldsa87 | N | This document.
References
Normative References
[FIPS204]

Module-Lattice-Based Digital Signature Standard
August 2024
DOI 10.6028/nist.fips.204
National Institute of Standards and Technology
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC5246]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 5246
DOI 10.17487/RFC5246
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[TLSIANA]

IANA Registry Updates for TLS and DTLS
Joseph A. Salowey
Venafi
Sean Turner
sn3rd
3 November 2024
Internet-Draft draft-ietf-tls-rfc8447bis-10
[I-D.ietf-lamps-dilithium-certificates]

Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA
Jake Massimo
AWS
Panos Kampanakis
AWS
Sean Turner
sn3rd
Bas Westerbaan
Cloudflare
4 November 2024
Internet-Draft draft-ietf-lamps-dilithium-certificates-05
Acknowledgments
Thanks to Alicja Kario and John Mattsson for their review and feedback.