]> Cisco Systems

sfluhrer@cisco.com

Sofia 1750 Bulgaria pkixssh@roumenpetrov.info https://roumenpetrov.info/secsh/

Bank of America

ryan.appel@bofa.com

sec sshm Module-Lattice-Based Digital Signature Standard ML-DSA Secure Shell SSH Secure remote-login Public Key Algorithm This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. 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). This document standardizes the use of the names ssh-mldsa-44, ssh-mldsa-65, and ssh-mldsa-87. These algorithms correspond to Table 1. "ML-DSA parameter sets" defined in Section 4 "Parameter Sets".

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 deterministic 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; they do 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

Standard implementations of SSH SHOULD implement mldsa-65 public Key algorithm. It MAY implement mldsa-44 and mldsa-87 public key algorithms.

Public Key Format

• The mldsa-44 key format has the following encoding:

  string

  ssh-mldsa-44

  string

  key

  Here, 'key' is the 1312-octet public key encoded as is described in Algorithm 22.
• The mldsa-65 key format has the following encoding:

  string

  ssh-mldsa-65

  string

  key

  Here, 'key' is the 1952-octet public key encoded as is described in Algorithm 22.
• The mldsa-87 key format has the following encoding:

  string

  ssh-mldsa-87

  string

  key

  Here, 'key' is the 2592-octet public key encoded as is described in Algorithm 22.

Private Key Format It is not required that the implementation be able to import or export private keys, but if it does, it SHOULD use good judgement on the methods in which keys can be imported and exported. Implementers and Users of these implementations should be aware that allows for the private key to be stored in either "seed" form or "expanded" form. While it is feasible for an implementation to expand the seed form of the private key to the expanded form, it is impossible to reverse this expansion. If one implementation only uses and stores the expanded form of the ML-DSA private key, exporting a key from that implementation to a different implementation that only supports seed format is impossible. Although Private key format is out of scope of this document, if an implementation stores a key in expanded form, it SHOULD also store the seed format of the same private key as to not prohibit interoperability.

Signature Algorithm Signatures are generated according to the procedure described in Section 5.2 of , and verified according to the procedure described in Section 5.3, using an empty string as the context parameter.

Signature Format

• The mldsa-44 public key algorithm has the following format for encoding the signature:

  string

  ssh-mldsa-44

  string

  signature

  Here, 'signature' is the 2420-octet signature produced in accordance with Algorithm 2.
• The mldsa-65 public key algorithm has the following format for encoding the signature:

  string

  ssh-mldsa-65

  string

  signature

  Here, 'signature' is the 3309-octet signature produced in accordance with Algorithm 2.
• The mldsa-87 public key algorithm has the following format for encoding the signature:

  string

  ssh-mldsa-87

  string

  signature

  Here, 'signature' is the 4627-octet signature produced in accordance with Algorithm 2.

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 , algorithm 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 document
ssh-mldsa-65	This document
ssh-mldsa-87	This document

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 document
TBD2	ML-DSA-65	This document
TBD3	ML-DSA-87	This document

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 Informative References 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 the original template for this document.