| Internet-Draft | SSH ML-DSA | March 2025 |
| Fluhrer | Expires 17 September 2025 | [Page] |
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://sfluhrer.github.io/ssh-mldsa/draft-sfluhrer-ssh-mldsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sfluhrer-ssh-mldsa/.¶
Discussion of this document takes place on the Secure Shell Maintenance Security Area mailing list (mailto:ssh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ssh/. Subscribe at https://www.ietf.org/mailman/listinfo/ssh/.¶
Source for this draft and an issue tracker can be found at https://github.com/sfluhrer/ssh-mldsa.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A Cryptographically Relevant Quantum Computer (CRQC) could break traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of SSH. NIST has recently published the postquantum digitial signature algorithm ML-DSA [FIPS204].¶
This document describes how to use this algorithm for authentication within SSH [RFC4251], as a replacement for the traditional signature algorithms (RSA, ECDSA).¶
ML-DSA (as specified in FIPS 204) is a signature algorithm that is believed to be secure against attackers who have a Quantum Computer available to them. There are three strengths defined for it (with the parameter sets being known as ML-DSA-44, ML-DSA-65 and ML-DSA-87). In addition, for each defined parameter set, there are two versions, the 'pure' version (where ML-DSA directly signs the message) and a 'prehashed' version (where ML-DSA signs a hash that was computed outside of ML-DSA). For this protocol, we will always use the pure version.¶
In addition, ML-DSA also has a 'context' input, which is a short string that is common to the sender and the recceiver. It is intended to allow for domain separation between separate uses of the same public key.¶
FIPS 204 also allows ML-DSA to be run in either determanistic or 'hedged' mode (where randomness is applied to the signature operation). We place no requirement on which is used; the implementation should select based on the quality of their random number source.¶
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.¶
The descriptions of key and signature formats use the notation introduced in [RFC4251], Section 3, and the string data type from [RFC4251], Section 5. Identifiers and terminology from ML-DSA [FIPS204] are used throughout the document.¶
This document describes three public key algorithms for use with SSH, as per [RFC4253], Section 6.6, corresponding to the three parameter sets of ML-DSA. The names of the algorithm are "ssh-ml-dsa-44", "ssh-ml-dsa-65" and "ssh-ml-dsa-87", to match the level 2, 3 and 5 parameter sets [FIPS204]. These algorithm only support signing and not encryption.¶
The key format for all three parameter sets have the following encoding:¶
string "ssh-mldsa44" (or "ssh-mldsa65" or "ssh-mldsa87")¶
string key¶
Here, 'key' is the public key described in [FIPS204].¶
# Signature Algorithm¶
Signatures are generated according to the procedure in Section 5.2 [FIPS204], using the "pure" version of ML-DSA, with an empty context string.¶
The "ssh-mldsa" key format has the following encoding:¶
string "ssh-mldsa44" (or "ssh-mldsa65" or "ssh-mldsa87")¶
string signature¶
Here, 'signature' is the signature produced in accordance with the previous section.¶
Signatures are verified according to the procedure in [FIPS204], Section 5.3, using the "pure" version of ML-DSA, with an empty context strong.¶
Usage and generation of the SSHFP DNS resource record is described in [RFC4255]. This section illustrates the generation of SSHFP resource records for ML-DSA keys, and this document also specifies the corresponding code point to "SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource Record Parameters" IANA registry [IANA-SSHFP].¶
The generation of SSHFP resource records keys for ML-DSA is described as follows.¶
The encoding of ML-DSA public keys is described in [FIPS204].¶
The SSHFP Resource Record for an ML-DSA key fingerprint (with a SHA-256 fingerprint) would, for example, be:¶
pqserver.example.com. IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f28267237 34d90ed316d2b818ca9580ea384d9240 )¶
Replace TBD with the value eventually allocated by IANA.¶
This document augments the Public Key Algorithm Names in [RFC4250], Section 4.11.3.¶
IANA is requested to add the following entries to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry [IANA-SSH]:¶
| Public Key Algorithm Name | Key Size | Signature Size | Reference |
|---|---|---|---|
| ssh-mldsa44 | 1312 | 2420 | THIS-RFC |
| ssh-mldsa65 | 1952 | 3309 | THIS-RFC |
| ssh-mldsa87 | 2592 | 4627 | THIS-RFC |
IANA is requested to add the following entries to "SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource Record Parameters" registry [IANA-SSHFP]:¶
| Value | Description | Reference |
|---|---|---|
| TBD1 | ML-DSA-44 | THIS RFC |
| TBD2 | ML-DSA-65 | THIS RFC |
| TBD3 | ML-DSA-87 | THIS RFC |
The security considerations in [RFC4251], Section 9 apply to all SSH implementations, including those using ML-DSA.¶
The security considerations in ML-DSA [FIPS204] apply to all uses of ML-DSA, including those in SSH.¶
Cryptographic algorithms and parameters are usually broken or weakened over time. Implementers and users need to continously re-evaluate that cryptographic algorithms continue to provide the expected level of security.¶
The text of draft-josefsson-ssh-sphincs was used as a template for this document.¶