]> Huawei

sunshuzhou@huawei.com

Huawei

lucas.prabel@huawei.com

Security sshm ssh Composite Signatures ML-DSA This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. 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 (sshm) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The development of quantum computers has raised concern towards traditional asymmetric cryptographic algorithms. A Cryptographically Relevant Quantum Computer (CRQC) will break RSA and elliptic curve signature schemes. There is a need to migrate to quantum-resistant signature schemes. Recently, NIST publised the ML-DSA algorithm, which is a post-quantum signature scheme. However, when using relatively new cryptographic schemes, the lack of maturing time makes people worry. Many hybrid solutions are thus proposed, which combine a traditional algorithm with a post-quantum algorithm. defines both pure ML-DSA and pre-hash ML-DSA. This document only uses pure ML-DSA. This document describes how to combine ML-DSA with the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 for authentication in the SSH 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. This document is consistent with the terminology for hybrid signatures defined in . The key and signature formats follows the notation introduced in , Section 3, and the string data type format follows the notation from , Section 5.

Composite Algorithms A composite algorithm has one post-quantum algorithm, and one traditional algorithm.

Composite Key Generation Composite public and private keys are generated by calling the key generation functions of the two component algorithms and concatenating the keys in an order given by the registered composite algorithm. For the composite algorithms described in this document, the Key Generation process is as follows: ECCSigAlg is an elliptic curve signature scheme, i.e., ECDSA, Ed25519 or Ed448.

Composite Sign A composite signature's value MUST include two signature components and MUST be in the same order as the components from the corresponding signing key. For the composite algorithms described in this document, the signature process of a message M follows Section 4.2.1 of , with an empty application context string: The prefix "Prefix" string is defined as in as the byte encoding of the string "CompositeAlgorithmSignatures2025", which in hex is 436F6D706F73697465416C676F726974686D5369676E61747572657332303235. It can be used by a traditional verifier to detect if the composite signature has been stripped apart. The domain separator "Domain" is defined as the octets of the ASCII representation of the key format identifier of the underlying composite signature algorithm.

Composite Verify The Verify algorithm MUST validate a signature only if all component signatures are successfully validated.

Public Key Algorithm This section gives the concrete composite signature algorithms and their component algorithms. Their usage within SSH follows Section 6.6 of . The following table defines a list of algorithms associated with specific PQ/T combinations. Composite ML-DSA Signature Algorithms for SSH

Key Format Identifier	First Algorithm	Second Algorithm	Pre-Hash	Description
ssh-mldsa44-es256	ML-DSA-44	ecdsa-with-SHA256 with secp256r1	id-sha256	Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256
ssh-mldsa65-es256	ML-DSA-65	ecdsa-with-SHA256 with secp256r1	id-sha256	Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256
ssh-mldsa87-es384	ML-DSA-87	ecdsa-with-SHA384 with secp384r1	id-sha384	Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384
ssh-mldsa44-ed25519	ML-DSA-44	Ed25519	id-sha512	Composite Signature with ML-DSA-44 and Ed25519 and SHA-512
ssh-mldsa65-ed25519	ML-DSA-65	Ed25519	id-sha512	Composite Signature with ML-DSA-65 and Ed25519 and SHA-512
ssh-mldsa87-ed448	ML-DSA-87	Ed448	id-sha512	Composite Signature with ML-DSA-87 and Ed448 and SHA-512

Public Key Format The key format for all parameter sets defined in this document follows the encoding pattern from , Section 6.6. string identifier string key The 'identifier' is the key format identifier given in . The 'key' is the composite public key generated as defined in . It is the concatenation of the public keys of the component schemes. For ML-DSA, the public keys are defined in . For ECDSA with curves secp256r1 or secp384r1, the public keys are defined in , Section 3.1. The public key is encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of ; point compression MAY be used. For Ed25519 and Ed448, the public keys are defined in , Section 6. The "ssh-mldsa44-es256" key format has the following encoding: string ssh-mldsa44-es256 string key Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the ECDSA public key using the secp256r1 curve. The "ssh-mldsa65-es256" key format has the following encoding: string ssh-mldsa65-es256 string key Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the ECDSA public key using the secp256r1 curve. The "ssh-mldsa87-es384" key format has the following encoding: string ssh-mldsa87-es384 string key Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the ECDSA public key using the secp384r1 curve. The "ssh-mldsa44-ed25519" key format has the following encoding: string ssh-mldsa44-ed25519 string key Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the 32-octet Ed25519 public key. The "ssh-mldsa65-ed25519" key format has the following encoding: string ssh-mldsa65-ed25519 string key Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the 32-octet Ed25519 public key. The "ssh-mldsa87-ed448" key format has the following encoding: string ssh-mldsa87-ed448 string key Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the 57-octet Ed448 public key.

Signature Format The signature format for all parameter sets defined in this document following the encoding pattern defined in Section 6.6 of . string identifier string signature The 'identifier' is the key format identifier given in . The 'signature' is the composite signature generated as defined in . It is the concatenation of the signatures of the component schemes. For ML-DSA, the signatures are defined in . For ECDSA with curves secp256r1 and secp384r1, the signatures and their encodings are defined in , Section 3.1.2. For Ed25519 and Ed448, the signature are defined in , Section 6. The "ssh-mldsa44-es256" key format has the following encoding: string ssh-mldsa44-es256 string signature Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the ECDSA signature using the secp256r1 curve. The "ssh-mldsa65-es256" key format has the following encoding: string ssh-mldsa65-es256 string signature Here, 'signature' is the concatenation of the 3309-octet ML-DSA-65 signature and the ECDSA signature using the secp256r1 curve. The "ssh-mldsa87-es384" key format has the following encoding: string ssh-mldsa87-es384 string signature Here, 'signature' is the concatenation of the 4627-octet ML-DSA-44 signature and the ECDSA signature using the secp384r1 curve. The "ssh-mldsa44-ed25519" key format has the following encoding: string ssh-mldsa44-ed25519 string signature Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the 64-octet Ed25519 signature. The "ssh-mldsa65-ed25519" key format has the following encoding: string ssh-mldsa65-ed25519 string signature Here, 'signature' is the concatenation of the 3309-octet ML-DSA-44 signature and the 64-octet Ed25519 signature. The "ssh-mldsa87-ed448" key format has the following encoding: string ssh-mldsa87-ed448 string signature Here, 'signature' is the concatenation of the 4627-octet ML-DSA-44 signature and the 114-octet Ed448 signature.

Security Considerations The Security Considerations section of also applies to this document. The user can refer to for security issues related to the ML-DSA post-quantum component of the composite algorithm and to the Security Considerations sections of and for the traditional component. For the specific security issues raising from the use of a hybrid composite signature scheme, the user can refer to .

IANA Considerations IANA is requested to add the following entries to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry : SSH Public Key Code Points

Public Key Algorithm Name	Key Format	Reference
ssh-mldsa44-es256	ssh-mldsa44-es256	THIS-RFC
ssh-mldsa65-es256	ssh-mldsa65-es256	THIS-RFC
ssh-mldsa87-es384	ssh-mldsa87-es384	THIS-RFC
ssh-mldsa44-ed25519	ssh-mldsa44-ed25519	THIS-RFC
ssh-mldsa65-ed25519	ssh-mldsa65-ed25519	THIS-RFC
ssh-mldsa87-ed448	ssh-mldsa87-ed448	THIS-RFC

References Normative 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] This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [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 the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. 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 n.d. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. SandboxAQ Naval Postgraduate School SandboxAQ UK National Cyber Security Centre This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums National Institute of Standards and Technology (NIST) Standards for Efficient Cryptography Group

Acknowledgments TODO acknowledge.