]> Cisco Systems

sfluhrer@cisco.com

Bank of America

ryan.appel@bofa.com

sec sshm ML-DSA This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Shell Maintenance Security Area mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A Cryptographically Relevant Quantum Computer (CRQC) is a quantum computer with sufficient compute capability and stability that it is able to break traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA; which are currently the only authentication algorithms available for SSH. NIST has recently published the post-quantum cryptography (PQC) algorithm known as ML-DSA which is a digital signature algorithm. This document describes how to use this algorithm for authentication within SSH , as a replacement for the traditional signature algorithms (RSA, ECDSA).

Background on ML-DSA ML-DSA (as specified in FIPS 204) is a signature algorithm that is believed to be secure against attackers who have a CRQC available to them. There are three parameter sets defined for it which belong to a respective NIST Security Category of 2, 3, and 5 (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 computes the hash of the message internally and then signs that hash), 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. This protocol always uses an empty (zero length) context. FIPS 204 also allows ML-DSA to be run in either determanistic or 'hedged' mode (where randomness is applied during the signature generation operation). We recommend that implementations use hedged mode, as it blocks certain side channel attacks. However, as both are interoperable, we do not place any requirement on which is used within this protocol.

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 when, and only when, they appear in all capitals, as shown here. The descriptions of key and signature formats use the notation introduced in , Section 3, and the string data type from , Section 5. Identifiers and terminology from ML-DSA are used throughout the document.

Public Key Algorithms This document describes three public key algorithms for use with SSH, as per , Section 6.6, corresponding to the three parameter sets of ML-DSA. The names of the algorithms are "ssh-mldsa-44", "ssh-mldsa-65" and "ssh-mldsa-87", to match the level 2, 3 and 5 parameter sets . These algorithm support only signing; it does not support encryption. The below table lists the public key sizes and the signature size (in bytes) for the three parameter sets.

Public Key Algorithm Name	Public Key Size	Signature Size
ssh-mldsa-44	1312	2420
ssh-mldsa-65	1952	3309
ssh-mldsa-87	2592	4627

Public Key Format The key format for all three parameter sets have the following encoding: string "ssh-mldsa-44" (or "ssh-mldsa-65" or "ssh-mldsa-87") string key Here, 'key' is the public key described in .

Signature Algorithm Signatures are generated according to the procedure in Section 5.2 , using the "pure" version of ML-DSA, with an empty context string.

Signature Format The "ssh-mldsa" key format has the following encoding: string "ssh-mldsa-44" (or "ssh-mldsa-65" or "ssh-mldsa-87") string signature Here, 'signature' is the signature produced in accordance with the previous section.

Verification Algorithm Signatures are verified in two steps. For the first step, the length of the signature must be checked against the parameter set, if the signature length does not match the expected signature length for the parameter set, it must be rejected. Then the signature is verified according to the procedure in , Section 5.3, using the "pure" version of ML-DSA, with an empty context string.

SSHFP DNS Resource Records Usage and generation of the SSHFP DNS resource record is described in . 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 . The generation of SSHFP resource records keys for ML-DSA is described as follows. The encoding of ML-DSA public keys is described as above in section 4. 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.

IANA Considerations This document augments the Public Key Algorithm Names in , 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 :

Public Key Algorithm Name	Reference
ssh-mldsa-44	THIS-RFC
ssh-mldsa-65	THIS-RFC
ssh-mldsa-87	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 :

Value	Description	Reference
TBD1	ML-DSA-44	THIS RFC
TBD2	ML-DSA-65	THIS RFC
TBD3	ML-DSA-87	THIS RFC

Security Considerations The security considerations in , Section 9 apply to all SSH implementations, including those using ML-DSA. The security considerations in ML-DSA 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK] The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK] The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK] n.d. n.d.

Acknowledgments The text of draft-josefsson-ssh-sphincs was used as a template for this document.