simon@josefsson.org

IETF Secure Shell Maintenance Sphincs+ SLH-DSA post quantum pq signature ssh secsh This document describes the use of Sphincs+/SLH-DSA digital signatures in the Secure Shell (SSH) protocol. Status information for this document may be found at . Discussion of this document takes place on the SSHM Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Secure Shell (SSH) is a secure remote-login protocol. It provides for an extensible variety of public key algorithms for identifying servers and users to one another. Sphincs+ is a stateless hash-based digital signature system, standardized in as Stateless Hash-Based Digital Signature Algorithm (SLH-DSA). This document specify how Sphincs+/SLH-DSA is used in SSH.

Conventions Used In This Document 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 SPHINCS are used throughout the document.

Requirements Language 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.

Public Key Algorithm This document describes a public key algorithm for use with SSH, as per , Section 6.6. The name of the algorithm is "ssh-slh-dsa-sha2-256f" to match SLH-DSA-SHA2-256F . This algorithm only supports signing and not encryption. SSH implementations SHOULD implement these signature algorithms.

Public Key Format The "ssh-slh-dsa-sha2-256f" key format has the following encoding:

Here, 'key' is the public key described in , for the SLH-DSA-SHA2-256F algorithm, Section 10.1.

Signature Algorithm Signatures are generated according to the procedure in Sections 10.2 , using the "pure" version of SLH-DSA-SHA2-256F.

Signature Format The "ssh-ed25519" key format has the following encoding:

Here, 'signature' is the signature produced in accordance with the previous section.

Verification Algorithm Signatures are verified according to the procedure in , Section 10.3, using the "pure" version of SLH-DSA-SHA2-256F.

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 SLH-DSA/Sphincs+ 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 SLH-DSA/Sphincs+ is described as follows. The encoding of SLH-DSA/Sphincs+ public keys is described in , Section 10.1. The public keys are short, so there is no need to use a hash algorithm to shorten them. We therefor describe a new "Fingerprint Type" value TBD2 to refer to the raw public-key value without hashing. The SSHFP Resource Record for a SLH-DSA/Sphincs+ key fingerprint would, for example, be:

Replace TBD1 and TBD2 with the values 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 entry to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry : Public Key Algorithm Name Key Size Signature Size Reference ssh-slh-dsa-sha2-256f 64 49856 THIS-RFC IANA is requested to add the following entry to "SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource Record Parameters" registry : Value Description Reference TBD1 SSH-SLH-DSA-SHA2-256F THIS-RFC IANA is requested to add the following entry to "SSHFP RR types for fingerprint types" in the "DNS SSHFP Resource Record Parameters" registry : Value Description Reference TBD2 raw THIS-RFC

Security Considerations The security considerations in , Section 9 apply to all SSH implementations, including those using Sphincs+/SLH-DSA. The security considerations in SPHINCS apply to all uses of Sphincs+/SLH-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.

Acknowledgments The text of was used as a template for this document.

Test vectors The following illustrate test vectors using file formats used by, for example, OpenSSH.

Private Key Private key:

Public-Key Public key:

Message The namespace context string used is "my-namespace", and the message is (including final newline):

Signature Signature:

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] 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. IANA IANA 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. SPHINCS+ Team