TLS T. Reddy Internet-Draft Nokia Intended status: Standards Track T. Hollebeek Expires: 6 May 2025 DigiCert J. Gray Entrust S. Fluhrer Cisco Systems 2 November 2024 Use of SLH-DSA in TLS 1.3 draft-tls-reddy-slhdsa-00 Abstract This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Reddy, et al. Expires 6 May 2025 [Page 1] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 2. SLH-DSA SignatureSchemes Types . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Stateless Hash-Based Digital Signatures (SLH-DSA) [FIPS205] 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. 1.1. 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 [RFC2119] [RFC8174] 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 [I-D.ietf-pquip-pqt-hybrid-terminology]. For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes: Reddy, et al. Expires 6 May 2025 [Page 2] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 "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. 2. 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 [FIPS180] or SHAKE256 [FIPS202] 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 [FIPS205]: * 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 Reddy, et al. Expires 6 May 2025 [Page 3] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 * 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 [RFC8446], 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. enum { slhdsa128s_sha256 (0x0911), slhdsa128f_sha256 (0x0912), slhdsa192s_sha256 (0x0913), slhdsa192f_sha256 (0x0914), slhdsa256s_sha256 (0x0915), slhdsa256f_sha256 (0x0916), slhdsa128s_shake (0x0917), slhdsa128f_shake (0x0918), slhdsa192s_shake (0x0919), slhdsa192f_shake (0x091A), slhdsa256s_shake (0x091B), slhdsa256f_shake (0x091C) } SignatureScheme; 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 [FIPS205]. Reddy, et al. Expires 6 May 2025 [Page 4] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 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 [FIPS205] Algorithm 23 MUST be an empty string. The signature MUST be computed and verified as specified in Section 4.4.3 of [RFC8446]. 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 [I-D.ietf-lamps-x509-slhdsa]}. The schemes defined in this document MUST NOT be used in TLS 1.2 [RFC5246]. 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. 3. Security Considerations The security considerations discussed in Section 11 of [I-D.ietf-lamps-x509-slhdsa] needs to be taken into account. 4. IANA Considerations This document requests new entries to the TLS SignatureScheme registry, according to the procedures in Section 6 of [TLSIANA]. Reddy, et al. Expires 6 May 2025 [Page 5] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 +========+===================+=============+================+ | 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. | +--------+-------------------+-------------+----------------+ Table 1 5. References 5.1. Normative References [I-D.ietf-lamps-x509-slhdsa] Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and S. Kousidis, "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA", Work in Progress, Internet-Draft, draft-ietf-lamps-x509-slhdsa-02, 14 October 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Reddy, et al. Expires 6 May 2025 [Page 6] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [TLSIANA] Salowey, J. A. and S. Turner, "IANA Registry Updates for TLS and DTLS", Work in Progress, Internet-Draft, draft- ietf-tls-rfc8447bis-09, 30 April 2024, . 5.2. Informative References [FIPS180] "NIST, Secure Hash Standard (SHS), FIPS PUB 180-4, August 2015", . [FIPS202] "NIST, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, FIPS PUB 202, August 2015.", . [FIPS205] "FIPS 205: Stateless Hash-Based Digital Signature Standard", . [I-D.ietf-pquip-pqt-hybrid-terminology] D, F., P, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", Work in Progress, Internet- Draft, draft-ietf-pquip-pqt-hybrid-terminology-04, 10 September 2024, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . Acknowledgments Thanks to Bas Westerbaan for the discussion and comments. Authors' Addresses Reddy, et al. Expires 6 May 2025 [Page 7] Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024 Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Timothy Hollebeek DigiCert Pittsburgh, United States of America Email: tim.hollebeek@digicert.com John Gray Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: john.gray@entrust.com Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.com Reddy, et al. Expires 6 May 2025 [Page 8]