]> Nokia

Bangalore Karnataka India kondtir@gmail.com

DigiCert

Pittsburgh USA tim.hollebeek@digicert.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Cisco Systems

sfluhrer@cisco.com

Security TLS SLH-DSA FIPS205 This memo specifies how the post-quantum signature scheme SLH-DSA is used for authentication in TLS 1.3.

Introduction Stateless Hash-Based Digital Signatures (SLH-DSA) is a quantum-resistant digital signature scheme standardized by the US National Institute of Standards and Technology (NIST) PQC project. This memo specifies how SLH-DSA can be negotiated for authentication in TLS 1.3 via the "signature_algorithms" and "signature_algorithms_cert" extensions.

Conventions and Terminology 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. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document uses terms defined in . For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes: "Asymmetric Traditional Cryptographic Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms. Examples of quantum-resistant digital signature schemes include ML-DSA and SLH-DSA.

SLH-DSA SignatureSchemes Types SLH-DSA utilizes the concept of stateless hash-based signatures. In contrast to stateful signature algorithms, SLH-DSA eliminates the need for maintaining state information during the signing process. SLH-DSA is designed to sign up to 2^64 messages and it offers three security levels. The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. This document specifies the use of the SLH-DSA algorithm in TLS at three security levels. It includes the small (S) or fast (F) versions of the algorithm and allows for the use of either SHA-256 or SHAKE256 as the hash function. The small version prioritizes smaller signature sizes, making them suitable for resource-constrained environments IoT devices. Conversely, the fast version prioritizes speed over signature size, minimizing the time required to generate and verify signatures. The following combinations are defined in SLH-DSA :

• SLH-DSA-128S-SHA2
• SLH-DSA-128F-SHA2
• SLH-DSA-192S-SHA2
• SLH-DSA-192F-SHA2
• SLH-DSA-256S-SHA2
• SLH-DSA-256F-SHA2
• SLH-DSA-128S-SHAKE
• SLH-DSA-128F-SHAKE
• SLH-DSA-192S-SHAKE
• SLH-DSA-192F-SHAKE
• SLH-DSA-256S-SHAKE
• SLH-DSA-256F-SHAKE

SLH-DSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptography, making it a reliable and robust digital signature scheme for a post-quantum world. While attacks on lattice-based schemes like ML-DSA can compromise their security, SLH-DSA will remain unaffected by these attacks due to its distinct mathematical foundations. This ensures the continued security of systems and protocols that utilize SLH-DSA for digital signatures. However, ML-DSA outperforms SLH-DSA in both signature generation and validation time, as well as signature size. SLH-DSA, in contrast, offers smaller key sizes but larger signature sizes. Due to its well-established hardness assumption, SLH-DSA can be preferred for CA certificates, making it ideal for long-term security as a trust anchor. ML-DSA, on the other hand, is well-suited for end-entity certificates as it provides the computational efficiency required for frequent, real-time authentication, such as during TLS handshake. As defined in , the SignatureScheme namespace is used for the negotiation of signature scheme for authentication via the "signature_algorithms" and "signature_algorithms_cert" extensions. This document adds new SignatureSchemes types for the SLH-DSA as follows. It is important to note that the slhdsa* entries represent the pure versions of these algorithms and should not be confused with prehashed variant HashSLH-DSA, also defined in . In TLS, the data used for generating a digital signature is unique for each TLS session, as it includes the entire handshake. Thus, SLH-DSA can utilize the deterministic version. The context parameter defined in Algorithm 23 MUST be an empty string. The signature MUST be computed and verified as specified in . The corresponding end-entity certificate when negotiated MUST use id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f, id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f, id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f, id-slh-dsa-shake-128s, id-slh-dsa-shake-128f, id-slh-dsa-shake-192s, id-slh-dsa-shake-192f, id-slh-dsa-shake-256s and id-slh-dsa-shake-256f respectively as defined in }. The schemes defined in this document MUST NOT be used in TLS 1.2 . A peer that receives ServerKeyExchange or CertificateVerify message in a TLS 1.2 connection with schemes defined in this document MUST abort the connection with an illegal_parameter alert.

Security Considerations The security considerations discussed in Section 11 of needs to be taken into account.

IANA Considerations This document requests new entries to the TLS SignatureScheme registry, according to the procedures in .

Value	Description	Recommended	Reference
0x0911	slhdsa128s_sha256	Y	This document.
0x0912	slhdsa128f_sha256	Y	This document.
0x0913	slhdsa192s_sha256	Y	This document.
0x0914	slhdsa192f_sha256	Y	This document.
0x0915	slhdsa256s_sha256	Y	This document.
0x0916	slhdsa256f_sha256	Y	This document.
0x0917	slhdsa128s_shake	Y	This document.
0x0918	slhdsa128f_shake	Y	This document.
0x0919	slhdsa192s_shake	Y	This document.
0x091A	slhdsa192f_shake	Y	This document.
0x091B	slhdsa256s_shake	Y	This document.
0x091C	slhdsa256f_shake	Y	This document.

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Venafi sn3rd This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. BSI Cisco Systems genua GmbH CryptoNext Security BSI Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also described. 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 specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] 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.

Acknowledgments Thanks to Bas Westerbaan for the discussion and comments.