Use of SLH-DSA in TLS 1.3
draft-reddy-tls-slhdsa-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Tim Hollebeek , John Gray , Scott Fluhrer | ||
| Last updated | 2024-11-15 | ||
| Replaces | draft-tls-reddy-slhdsa | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reddy-tls-slhdsa-00
TLS T. Reddy
Internet-Draft Nokia
Intended status: Standards Track T. Hollebeek
Expires: 19 May 2025 DigiCert
J. Gray
Entrust
S. Fluhrer
Cisco Systems
15 November 2024
Use of SLH-DSA in TLS 1.3
draft-reddy-tls-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 19 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Reddy, et al. Expires 19 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 . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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 19 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. For security level 1, SHA-256
([FIPS180]) is used. For security levels 3 and 5, SHA-512
([FIPS180]) is used. SHAKE256 ([FIPS202]) is applicable for all
security levels.
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.
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
Reddy, et al. Expires 19 May 2025 [Page 3]
Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024
* 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 can compromise their
security, SLH-DSA will 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 [PQ-TLS-TTLB] 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 [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.
Reddy, et al. Expires 19 May 2025 [Page 4]
Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024
enum {
slhdsa_sha2_128s (0x0911),
slhdsa_sha2_128f (0x0912),
slhdsa_sha2_192s (0x0913),
slhdsa_sha2_192f (0x0914),
slhdsa_sha2_256s (0x0915),
slhdsa_sha2_256f (0x0916),
slhdsa_shake_128s (0x0917),
slhdsa_shake_128f (0x0918),
slhdsa_shake_192s (0x0919),
slhdsa_shake_192f (0x091A),
slhdsa_shake_256s (0x091B),
slhdsa_shake_256f (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].
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.
Reddy, et al. Expires 19 May 2025 [Page 5]
Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024
4. IANA Considerations
This document requests new entries to the TLS SignatureScheme
registry, according to the procedures in Section 6 of [TLSIANA].
+========+===================+=============+================+
| Value | Description | Recommended | Reference |
+========+===================+=============+================+
| 0x0911 | slhdsa_sha2_128s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0912 | slhdsa_sha2_128f | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0913 | slhdsa_sha2_192s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0914 | slhdsa_sha2_192f | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0915 | slhdsa_sha2_256s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0916 | slhdsa_sha2_256f | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0917 | slhdsa_shake_128s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0918 | slhdsa_shake_128f | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x0919 | slhdsa_shake_192s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x091A | slhdsa_shake_192f | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x091B | slhdsa_shake_256s | Y | This document. |
+--------+-------------------+-------------+----------------+
| 0x091C | slhdsa_shake_256f | 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, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-x509-slhdsa-02>.
Reddy, et al. Expires 19 May 2025 [Page 6]
Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[TLSIANA] Salowey, J. A. and S. Turner, "IANA Registry Updates for
TLS and DTLS", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8447bis-10, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8447bis-10>.
5.2. Informative References
[FIPS180] "NIST, Secure Hash Standard (SHS), FIPS PUB 180-4, August
2015", <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[FIPS202] "NIST, SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions, FIPS PUB 202, August 2015.",
<https://nvlpubs.nist.gov/nistpubs/fips/
nist.fips.202.pdf>.
[FIPS205] "FIPS 205: Stateless Hash-Based Digital Signature
Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.205.pdf>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-pquip-pqt-hybrid-terminology-04>.
[PQ-TLS-TTLB]
"The impact of data-heavy, post-quantum TLS 1.3 on the
time-to-last-byte of real-world connections.",
<https://www.amazon.science/publications/the-impact-of-
data-heavy-post-quantum-tls-1-3-on-the-time-to-last-byte-
of-real-world-connections>.
Reddy, et al. Expires 19 May 2025 [Page 7]
Internet-Draft Use of SLH-DSA in TLS 1.3 November 2024
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
Acknowledgments
Thanks to Bas Westerbaan, John Mattsson, D.J. Bernstein, Alicja
Kario, and Peter Campbell for the discussion and comments.
Authors' Addresses
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 19 May 2025 [Page 8]