Internet DRAFT - draft-fregly-dnsop-slh-dsa-mtl-dnssec
draft-fregly-dnsop-slh-dsa-mtl-dnssec
DNSOP Working Group A.M. Fregly
Internet-Draft J. Harvey
Intended status: Standards Track B. Kaliski
Expires: 21 June 2024 D. Wessels
Verisign Labs
19 December 2023
Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL)
for DNSSEC
draft-fregly-dnsop-slh-dsa-mtl-dnssec-00
Abstract
This document describes how to apply the Stateless Hash-Based Digital
Signature Algorithm in Merkle Tree Ladder mode to the DNS Security
Extensions. This combination is referred to as the SLH-DSA-MTL
Signature scheme. This document describes how to specify SLH-DSA-MTL
keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE
family of hash functions. This document also provides guidance for
use of EDNS(0) in signature retrieval.
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 21 June 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Fregly, et al. Expires 21 June 2024 [Page 1]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
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
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 4
4. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . 4
5. Algorithm Numbers for DS, DNSKEY, and RRSIG Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. The mtl-mode-full EDNS(0) Option . . . . . . . . . . . . . . 6
6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Use By Responders . . . . . . . . . . . . . . . . . . . . 6
7. Implementation Considerations . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
13. Normative References . . . . . . . . . . . . . . . . . . . . 9
14. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The Domain Name System Security Extensions (DNSSEC), which are
broadly defined in [RFC4033], [RFC4034] and [RFC4035], use
cryptographic keys and digital signatures to provide data origin
authentication and data integrity in the DNS. This document
describes the application of Merkle Tree Ladder (MTL) Mode to the
Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) as the
SLH-DSA-MTL signature scheme for DNSSEC. SLH-DSA is described in the
FIPS 205 draft standard [FIPS205] and MTL mode is described in [MTL].
As described herein, a DNSKEY resource record (RR) for an SLH-DSA-MTL
key contains a SLH-DSA key. The SLH-DSA key is used for verifying
signatures on Merkle tree ladders (MTLs). An RRSIG resource record
for an SLH-DSA-MTL Signature contains a Merkle proof (authentication
path) that is verifiable using a MTL, and optionally also contains
the signed MTL.
The anticipation of quantum computers that can break the current
signature algorithms led to NIST selecting post-quantum cryptographic
(PQC) algorithms for standardization and developing specifications
for the algorithms as NIST standards. These new algorithms are
Fregly, et al. Expires 21 June 2024 [Page 2]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
expected to replace classical digital signature algorithms (e.g., RSA
and ECDSA) in IETF standards and to be widely implemented and
deployed after that. NIST's proposed PQC algorithms have
significantly larger signature sizes than RSA and ECDSA. The larger
sizes may have a significant operational impact on DNSSEC. For
example, the size of signed NSEC and NSEC3 responses may exceed UDP
MTUs with this degrading the use of UDP as the prevalent DNSSEC
transport. Larger signature sizes could also substantially increase
memory requirements for in-memory zone databases used by
authoritative name servers and for in-memory caches used by
resolvers.
As described in [MTL], MTL mode is designed to reduce the size impact
of PQC signature algorithms. For DNSSEC, the size impact reduction
is achieved when signatures provided in RRSIG RRs are primarily
comprised of "condensed signatures" (Merkle proofs / authentication
paths) and are only occasionally comprised of "full signatures" that
contain both a condensed signature and a signed MTL, where the signed
ladder includes a signature using the underlying PQC signature
algorithm. MTL mode reduces the memory requirements for PQC
signatures as the signature data in the zone database or cache is
primarily comprised of Merkle proofs and only occasionally of signed
MTLs [CTRSAMTL].
SLH-DSA is a stateless hash-based PQC signature scheme selected by
NIST for standardization [NISTSELECTIONS] in July 2022. This
document specifies SLH-DSA for the initial application of MTL mode to
DNSSEC based on three considerations: (1) SLH-DSA is also based on
Merkle trees, and thus already has internal functions for computing
leaf nodes and internal nodes; and (2) SLH-DSA has relatively large
signature sizes and computational costs, and therefore can benefit
significantly from the reductions offered by MTL mode; and (3) hash-
based techniques are well understood and offer a conservative choice
for long-term security relative to newer NIST selected signature
schemes based on lattice-based cryptography. SLH-DSA is based on
SPHINCS+ [SPHINCSPLUS], one of the submissions to NIST's PQC
evaluation project, and the algorithms are substantially the same.
[MTL] describes the combination of MTL mode with SPHINCS+. The
authors intend to update both [MTL] and this I-D as needed to be
consistent with FIPS 205 once it is published as a NIST FIPS
standard.
Fregly, et al. Expires 21 June 2024 [Page 3]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
This initial version of the draft focuses on the code-points
applicable to DNSKEY and RRSIG formulation and a proposed DNSSEC
protocol change to support retrieval of MTL mode condensed signatures
and MTL mode full signatures as described in 3., 9.4., and 9.5. of
[MTL]. Later versions may describe DNSSEC protocol and/or
operational changes related to zone signing, zone composition, zone
updates, zone transfer, name server processing, resolver signature
processing, and resolver caching.
2. Conventions Used in This Document
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.
Double pipe characters, "||" are used in this document to indicate
concatenation of the elements preceding and following the double pipe
characters.
All numeric DNSKEY elements and RRSIG elements specified in this
document are unsigned integers in network byte order (big endian
order).
3. DNSKEY Resource Records
An SLHDSAMTLSHA2128S key consists of a 32-octet value, which is
encoded into the Public Key field of a DNSKEY resource record as a
simple bit string. SLHDSAMTLSHA2128S keys are generated as SLH-DSA
keys using the SLH-DSA-SHA2-128s parameter set, as defined in 9.1 and
10 of [FIPS205].
An SLHDSAMTLSHAKE128S key consists of a 32-octet value, which is
encoded into the Public Key field of a DNSKEY resource record as a
simple bit string. SLHDSAMTLSHAKE128S keys are generated as SLH-DSA
keys using the SLH-DSA-SHAKE-128s parameter set, as defined in 9.1
and 10 of [FIPS205].
4. RRSIG Resource Records
MTL mode signatures are either full or condensed as described in
[MTL]. SLHDSAMTLSHA2128S and SLHDSAMTLSHAKE128S signatures utilize a
one-octet prefixed MTL-Type field to indicate whether the signature
is condensed (0) or full (1).
Fregly, et al. Expires 21 June 2024 [Page 4]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
An SLHDSAMTLSHA2128S signature consists of a variable-length value,
which is encoded into the Signature field of an RRSIG resource record
as a simple bit string as the concatenation of the MTL-Type and a
SLH-DSA-MTL-SHA2-128s signature as described in [MTL]:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTL-Type | |
+-+-+-+-+-+-+-+-+ |
| SLH-DSA-MTL-SHA2-128s signature |
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An SLHDSAMTLSHAKE128S signature consists of a variable-length value,
which is encoded into the Signature field of an RRSIG resource record
as a simple bit string as the concatenation of the MTL-Type and a
SLH-DSA-MTL-SHAKE-128s signature as described in [MTL]:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTL-Type | |
+-+-+-+-+-+-+-+-+ |
| SLH-DSA-MTL-SHAKE-128s signature |
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The signature and verification algorithms for both SLH-DSA-MTL-
SHA2-128s and SLH-DSA-MTL-SHAKE-128s are described in 9.1. and 9.2.
of [MTL]. The signature and verification algorithms for the
underlying signature algorithms used for signed ladders elements of
SLH-DSA-MTL-SHA2-128s and SLH-DSA-MTL-SHAKE-128s full signatures,
SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s respectively, are described
in 9.2 and 9.3 of [FIPS205].
5. Algorithm Numbers for DS, DNSKEY, and RRSIG Resource Records
The algorithm number associated with the use of SLHDSAMTLSHA2128S in
DS, DNSKEY, and RRSIG resource records is TBD. The algorithm number
associated with the use of SLHDSAMTLSHAKE128S in DS, DNSKEY, and
RRSIG resource records is TBD. This registration is fully defined in
the IANA Considerations section.
Fregly, et al. Expires 21 June 2024 [Page 5]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
6. The mtl-mode-full EDNS(0) Option
MTL mode signatures are either full or condensed. An MTL mode-aware
client MAY request that signatures be returned in the full format by
providing the mtl-mode-full EDNS(0) option in the OPT meta-RR of its
query [RFC6891].
6.1. Option Format
The mtl-mode-full option is encoded as follows:
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1
where:
OPTION-CODE The EDNS0 option code assigned to mtl-mode-full, TBD.
OPTION-LENGTH Always zero.
6.2. Use By Responders
When a query includes the mtl-mode-full option, the response
requirement depends on the number of RRSIG records in the response
that were produced in MTL mode:
* If exactly one RRSIG record in the response was produced in MTL
mode, then that RRSIG record MUST be returned in the full
signature format.
* If more than one RRSIG record in the response was produced in MTL
mode, then enough of these RRSIG records MUST be returned in the
full signature format to ensure that every other RRSIG in the
response that was produced in MTL mode can be verified.
When the mtl-mode-full option is not included, every signature in the
response that was produced in MTL mode MUST be returned in the
condensed signature format.
As described in 9.2. of [MTL], when a verifier receives a condensed
signature, the verifier determines whether any of the MTLs it has
previously verified includes a rung that is compatible with the
Fregly, et al. Expires 21 June 2024 [Page 6]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
authentication path in the condensed signature. If not, then the
verifier requests a new signed ladder. Accordingly, a resolver
SHOULD first query a name server without the mtl-mode-full option,
and then, if needed, re-issue the query with the mtl-mode-full
option. Since responses to queries with the mtl-mode-full option are
expected to be large, it is RECOMMENDED that queries with the mtl-
mode-full option be issued over transports (e.g., TCP, TLS, QUIC)
that support large responses without truncation and/or fragmentation.
7. Implementation Considerations
TBD
8. Examples
TBD
9. IANA Considerations
This document updates the IANA registry for DNSSEC "Domain Name
System Security (DNSSEC) Algorithm Numbers" located at
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-
numbers.xhtml. The following entries are requested to be added to
the registry subject to the Number update:
SLH-DSA-MTL-SHA2-128s
+--------------+--------------------------------+
| Number | TBD |
| Description | SLH-DSA-MTL-SHA2-128s |
| Mnemonic | SLHDSAMTLSHA2128S |
| Zone Signing | Y |
| Trans. Sec. | * |
| Reference | This specification |
+--------------+--------------------------------+
SLH-DSA-MTL-SHAKE-128s
+--------------+--------------------------------+
| Number | TBD |
| Description | SLH-DSA-MTL-SHAKE-128s |
| Mnemonic | SLHDSAMTLSHAKE128S |
| Zone Signing | Y |
| Trans. Sec. | * |
| Reference | This specification |
+--------------+--------------------------------+
Fregly, et al. Expires 21 June 2024 [Page 7]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
* There has been no determination of standardization of the use of
these algorithms with Transaction Security.
10. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Implementation details are TBD.
11. Security Considerations
The security considerations of [FIPS205] and [MTL] are inherited in
the usage of SLH-DSA-MTL in DNSSEC.
SLH-DSA-MTL-SHA2-128s and SLH-DSA-MTL-SHAKE-128s are intended to
operate at around the 128-bit security level against classical
attacks and the 64-bit level against quantum attacks, consistent with
NIST's security level I.
A private key used for a DNSSEC zone MUST NOT be used for any other
purpose than for that zone. Otherwise, cross-protocol or cross-
application attacks are possible.
Fregly, et al. Expires 21 June 2024 [Page 8]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
12. Acknowledgements
The authors would like to acknowledge the following individuals for
their contributions to the development of this document: Scott
Hollenbeck, Swapneel Sheth. This I-D has drawn from helpful examples
of document structure and specification text from various DNSSEC
algorithm RFCs. The authors express their gratitude to the authors
of those RFCs for their contributions.
13. Normative References
[FIPS205] National Institute of Standards and Technology (NIST),
"Stateless Hash-Based Digital Signature Standards", August
2023, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.205.ipd.pdf>. The target document is a draft
NIST Standard intended for finalization in 2024. Some
caution should be used since it may be less stable than
this document. This reference is appropriate as the NIST
standard is expected to be used in IETF standards.
[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/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[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/info/rfc8174>.
Fregly, et al. Expires 21 June 2024 [Page 9]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
14. Informative References
[CTRSAMTL] Kaliski, B., Fregly, A.M., Harvey, J., and S. Sheth,
"Merkle Tree Ladder Mode: Reducing the Size Impact of NIST
PQC Signature Algorithms in Practice", 2023.
[MTL] Harvey, J., Kaliski, B., Fregly, A.M., and S. Sheth,
"Merkle Tree Ladder Mode (MTL) Signatures", Work in
Progress, Internet-Draft, draft-harvey-cfrg-mtl-mode, June
2023, <https://datatracker.ietf.org/doc/draft-harvey-cfrg-
mtl-mode/>.
[NISTSELECTIONS]
National Institute of Standards and Technology (NIST),
"Status Report on the Third Round of the NIST Post-Quantum
Cryptography Standardization Process", NISTIR NIST.IR,
June 2022, <https://nvlpubs.nist.gov/nistpubs/ir/2022/
NIST.IR.8413-upd1.pdf>.
[SPHINCSPLUS]
Bernstein, D., Huelsing, A., Koelbl, S., Niederhagen, R.,
Rijneveld, J., and P. Schwabe, "The SPHINCS+ Signature
Framework", Cryptology ePrint Archive, Report 2019/1086,
2019, <https://eprint.iacr.org/2019/1086.pdf>.
Appendix A. Change Log
Initial draft
Authors' Addresses
A. Fregly
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: afregly@verisign.com
URI: http://www.verisignlabs.com/
J. Harvey
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: jsharvey@verisign.com
URI: https://www.verisignlabs.com/
Fregly, et al. Expires 21 June 2024 [Page 10]
Internet-Draft SLH-DSA-MTL-DNSSEC December 2023
B. Kaliski
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: bkaliski@verisign.com
URI: https://www.verisignlabs.com/
D. Wessels
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: dwessels@verisign.com
URI: https://www.verisignlabs.com/
Fregly, et al. Expires 21 June 2024 [Page 11]
