]> Cisco Systems

sfluhrer@cisco.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) 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 . 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 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. 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 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.

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 algorithm are "ssh-mldsa-44", "ssh-mldsa-65" and "ssh-mldsa-87", to match the level 2, 3 and 5 parameter sets . These algorithm only support signing and not 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 according to the procedure in , Section 5.3, using the "pure" version of ML-DSA, with an empty context strong.

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 in . 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 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.