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

Applicability of SLH-DSA Applications that use SLH-DSA need to be aware that the signature sizes of the algorithms specified in this document are generally large. SLH-DSA offers three security levels: 1, 3, and 5, and two parameter variants for each level:

• Small (s) variant, which are optimized for minimal signature size, have signature sizes ranging from 7856 bytes (128-bit) to 29792 bytes (256-bit).
• Fast (f) variant, optimized for faster key generation and signing, have signature sizes ranging from 17088 bytes (128-bit) to 29792 bytes (256-bit). However, they are slower at signature verification.

Despite offering trade-offs between size and performance, all SLH-DSA variants produce significantly larger signatures than traditional signature algorithms. While SLH-DSA increases the size of the TLS 1.3 handshake, its impact on connection performance is minimal in the context of large data transfers, especially over low-loss networks. For instancee, TLS-based protocols are increasingly used to secure long-lived interfaces in critical infrastructure, such as telecommunication networks. In particular, DTLS-in-SCTP has been mandated in 3GPP for interfaces such as N2 that use long-lived TLS connections. In deployments aiming to minimize handshake size, SLH-DSA may still be adopted for signing X.509 certificates while avoiding its use in the CertificateVerify message, which involves generating a signature over the entire TLS handshake transcript. This helps avoid performance concerns related to large signatures or expensive verification. SLH-DSA is well suited for enhancing the post-quantum security of root and intermediate certificates without affecting TLS handshake performance. Mechanisms such as Abridged TLS Certificate Chains and Suppressing CA Certificates reduce handshake size by limiting certificate exchange to only end-entity certificates. In such cases, intermediate certificates are assumed to be known to the peer, allowing the use of larger signature algorithms like SLH-DSA for those certificates without adding overhead to the handshake.

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 security levels 1, 3, and 5 were chosen to provide the equivalent of AES-128, AES-192, and AES-256 level of security respectively (see Table 2 in Section 10 of ). This document specifies the use of the SLH-DSA algorithm in TLS at three security levels. Each security level (1, 3, and 5) defines two variants of the algorithm: a small (S) version and a fast (F) version. 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 signatures. However, signature verification with the small version is faster than with the fast version. For hash function selection, the algorithm uses SHA-256 () for security level 1 and both SHA-256 and SHA-512 () for security levels 3 and 5. Alternatively, SHAKE256 () can be used across all security levels. 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 any new hardness assumptions beyond those inherent to its 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 are currently hypothetical at the time of writing this document, such attacks, if realized, could compromise their security. SLH-DSA would remain unaffected by these attacks due to its distinct mathematical foundations. This ensures the ongoing security of systems and protocols that use SLH-DSA for digital signatures. However, ML-DSA outperforms SLH-DSA in both signature generation and validation time, as well as in signature size, making it a recommended choice for end-entity certificates. SLH-DSA, in contrast, offers smaller key sizes but larger signature sizes. Given its well-established hardness assumption, SLH-DSA may be preferred for TLS applications where high confidence in security is a priority, such as for long-lived TLS sessions and deployments where computational costs of signature generation and validation are minor compared to data transmission and processing demands of user data. The findings in shows that while PQ algorithms increase the TLS 1.3 handshake data size, their effect on connection performance is minimal for large data transfers, especially in low-loss networks. Additionally, SLH-DSA is suitable for use in CA certificates due to its strong cryptographic assurances and smaller key sizes. Its robustness against emerging quantum attacks makes it a dependable choice for trust anchors and long-term security, even though it has larger signature sizes. 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 . SLH-DSA supports two signing modes: deterministic and hedged. In the deterministic mode, the signature is derived solely from the message and the private key, without requiring fresh randomness at signing time, this eliminates dependence on an external random number generator (RNG). It instead uses a precomputed randomness embedded in the private key. The hedged mode incorporates both fresh randomness generated at signing time, as well as the precomputed randomness, thereby offering somewhat stronger assurances. In the context of TLS, authentication signatures are computed over unique handshake transcripts, making each signature input distinct for every session. This property allows the use of either signing mode. The choice between deterministic and hedged modes does not affect interoperability, as the verification process is the same for both. In both modes, the context parameter defined in Algorithm 22 and Algorithm 24 of MUST be set to the 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.

SLH-DSA Variant Selection Guidance When deploying SLH-DSA in TLS 1.3, the choice of variant involves trade-offs among signing speed, verification cost, signature size, and the underlying hash function. The decision depends heavily on the characteristics and constraints of the target environment. If SHAKE is supported and offers acceptable performance, SHAKE-based variants are generally recommended for their performance and flexibility. In environments where SHAKE is unavailable or performs poorly, SHA-2 based variants offer comparable security and are a suitable alternative. The choice between "fast" and "small" variants depends on whether signing or verification performance is more critical in the target environment. Fast variants provide significantly faster signing but incur higher verification costs. Conversely, small variants enable more efficient verification but have slower signing performance. Security level requirements also guide the selection. If 128-bit security is sufficient, 128-bit variants can be used. For applications requiring higher assurance, 192-bit or 256-bit variants may be more appropriate.

Security Considerations The security considerations discussed in Section 9 of need to be taken into account. SLH-DSA imposes an upper bound of 2^64 signatures per key. If a key pair were used to sign 10 billion messages per second, it would take over 58 years to sign 2^64 messages. While this limit is extremely large, it may need to be considered if a single SLH-DSA private key was shared between a huge number of TLS servers all making extremely frequent negotiations.

Key Lifetime Management In order to maintain cryptographic safety in high-scale environments, deployments MUST:

• Rotate SLH-DSA certificates and keys based on expected signature usage, ensuring ample margin from the 2^64 signature limit.
• Monitor the number of signatures generated per SLH-DSA private key to ensure it
  remains well below the 2^64 signature limit.

IANA Considerations This document requests twelve new entries to the TLS Named Group (or Supported Group) registry, according to the procedures in Section 6 of .

Value	Description	Recommended	Reference
0x0911	slhdsa_sha2_128s	N	This document.
0x0912	slhdsa_sha2_128f	N	This document.
0x0913	slhdsa_sha2_192s	N	This document.
0x0914	slhdsa_sha2_192f	N	This document.
0x0915	slhdsa_sha2_256s	N	This document.
0x0916	slhdsa_sha2_256f	N	This document.
0x0917	slhdsa_shake_128s	N	This document.
0x0918	slhdsa_shake_128f	N	This document.
0x0919	slhdsa_shake_192s	N	This document.
0x091A	slhdsa_shake_192f	N	This document.
0x091B	slhdsa_shake_256s	N	This document.
0x091C	slhdsa_shake_256f	N	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 and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 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 specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. 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] This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. 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. Mozilla This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. AWS AWS Cloudflare Mozilla A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.

Acknowledgments Thanks to Bas Westerbaan, John Mattsson, D.J. Bernstein, Alicja Kario, and Peter Campbell for the discussion and comments.