Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC
draft-kaizer-dnsop-ml-dsa-mtl-dnssec-03
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 | Andrew Kaizer , Joe Harvey , Burt Kaliski , Swapneel Sheth | ||
| Last updated | 2026-10-19 | ||
| 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-kaizer-dnsop-ml-dsa-mtl-dnssec-03
DNSOP Working Group A. Kaizer
Internet-Draft J. Harvey
Intended status: Standards Track B. Kaliski
Expires: 22 April 2027 S. Sheth
Verisign Labs
19 October 2026
Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL)
for DNSSEC
draft-kaizer-dnsop-ml-dsa-mtl-dnssec-03
Abstract
This document describes how to apply the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA) and Merkle Tree Ladders (MTL) as a
conservative post-quantum cryptographic algorithm for DNS Security
Extensions (DNSSEC). This combination is referred to as the ML-DSA-
MTL Signature scheme. This document describes how to specify ML-DSA-
MTL keys and signatures in DNSSEC, specifically for ML-DSA-44 with
SHAKE-128.
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 22 April 2027.
Copyright Notice
Copyright (c) 2026 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
Kaizer, et al. Expires 22 April 2027 [Page 1]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Binary Rung Strategy . . . . . . . . . . . . . . . . . . 4
1.3.1. Related Work . . . . . . . . . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . . 7
3. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 7
4. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . 7
5. MTL Implementation Details . . . . . . . . . . . . . . . . . 8
5.1. Full Signatures . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Condensed Signatures . . . . . . . . . . . . . . . . 8
5.1.2. Signed Ladder . . . . . . . . . . . . . . . . . . . . 10
5.2. MTL Hash Function Instantiation . . . . . . . . . . . . . 11
5.3. MTL Signature Coverage . . . . . . . . . . . . . . . . . 12
6. Algorithm Numbers for DS, DNSKEY, and RRSIG Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Implementation Considerations . . . . . . . . . . . . . . . . 13
7.1. Batch Signing . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Online Signing . . . . . . . . . . . . . . . . . . . . . 13
7.3. Client Optimizations with Signed Ladders . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. DNSSEC Algorithm Number . . . . . . . . . . . . . . . . . 14
8.2. MTL Type Registry . . . . . . . . . . . . . . . . . . . . 14
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Signer Steps . . . . . . . . . . . . . . . . . . . . 19
Appendix C. Verifier Steps . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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.
Kaizer, et al. Expires 22 April 2027 [Page 2]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
This document describes the application of Merkle Tree Ladders (MTL)
[MTL-MODE] to the Module-Lattice-Based Digital Signature Algorithm
(ML-DSA) [FIPS204], referred to generally as ML-DSA-MTL. This
document specifically defines the use of ML-DSA-44 with SHAKE-128 as
defined in [FIPS204] as the ML-DSA-44-MTL-SHAKE-128 signature scheme
for DNSSEC.
As described herein, a DNSKEY resource record (RR) for an ML-DSA-MTL
key contains a ML-DSA key. The ML-DSA key is used for verifying
signatures on MTL authentication data. An RRSIG resource record for
an ML-DSA-MTL Signature contains a Merkle proof (authentication path)
and signed MTL. A signed MTL with a Merkle proof can be verified in
a single response, similar to how existing DNSSEC algorithms operate
today.
This draft focuses on the code-points applicable to DNSKEY and RRSIG
formulation. Later versions or other drafts may describe DNSSEC
protocol and/or operational guidance for zone signing, zone
composition, zone updates, zone transfer, name server processing,
resolver signature processing, resolver caching, or other potential
optimizations related to MTL.
1.1. Motivation
This document provides a conservatively designed PQC algorithm for
DNSSEC as described in [I-D.sheth-pqc-dnssec-strategy] using MTL
[MTL-MODE] and ML-DSA [FIPS204]. The cryptographic operations for
applying MTL to ML-DSA in the DNSSEC use case are specified within
this document. The reader does not need to be familiar with the more
general [MTL-MODE] specification to implement the ML-DSA-MTL
signature scheme for DNSSEC.
MTL is designed to reduce the size, memory, and computational impact
of PQC signature algorithms. For DNSSEC, MTL reduces the size and
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]. It also reduces the
computational requirements as only the full signature incurs the
signing and/or verification overhead of the underlying algorithm.
ML-DSA was formally published as a standard by NIST in August 2024
[FIPS204]. This document selected ML-DSA as one application of MTL
to DNSSEC because lattice-based techniques are well understood and
offer a conservative choice for long-term security relative to newer
NIST candidate post-quantum signature schemes.
Kaizer, et al. Expires 22 April 2027 [Page 3]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
1.2. Definitions
The provided terms in alphabetical order describe concepts utilized
in this document.
Authentication Path The set of sibling hash values from a leaf hash
value to a rung.
Index An integer value I that identifies a leaf node in a node set.
Indexes start at 0 and are consecutively assigned.
Index Pair A pair of integer values (L,R) that together identify a
node in a node set based on the lowest and highest indexes of the
consecutively-indexed leaf nodes that the node authenticates. For
a leaf node, the index pair is (I,I) which is used interchangeably
with the leaf index I.
Internal Node A node in a node set whose value is the hash of two
child nodes.
Ladder/Merkle Tree Ladder (MTL) A collection of one or more rungs
that can be used to verify an authentication path.
Leaf Node A node in a node set whose value is the hash of a single
message.
Message A set of bytes that are intended to be signed and later
verified.
Node Set An evolving set of hash nodes, each of which is part of a
union of tree structures either as a leaf node or an internal
node. A node set is acyclic, i.e., every node is either a leaf
node or the ancestor of two or more leaf nodes, and no node is an
ancestor of itself. Every node set has one or more root nodes.
Root Node A node in a node set that has no ancestors.
Rung A node from a node set that can be used to authenticate one or
more leaf nodes within that node set. A rung may be a root node.
Series Identifier (SID) A unique value associated with an instance
of a MTL node set.
1.3. Binary Rung Strategy
In the MTL operations in this document, the ladder is selected
according to what is called the binary rung strategy. In this
strategy, the index pairs for the rungs are based on the binary
representation of the number of messages in the message series. More
specifically, the first rung is the apex of the largest perfect
binary tree that can be formed from the leaf nodes corresponding to
the messages, starting from the left; the second rung is the apex of
the largest perfect binary tree that can be formed from the remaining
leaf nodes; and so on. The sizes of the trees decrease from left to
right.
Kaizer, et al. Expires 22 April 2027 [Page 4]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
The following figure shows a node set with 14 leaf nodes based on
this strategy. The internal node hash function is denoted H and the
leaf node hash function is not shown. The rungs are marked with
asterisks (*).
(0,7)*
|
H
/------/ \------\
(0,3) (4,7) (8,11)*
| | |
H H H
/--/ \--\ /--/ \--\ /--/ \--\
(0,1) (2,3) (4,5) (6,7) (8,9) (10,11) (12,13)*
| | | | | | |
H H H H H H H
/ \ / \ / \ / \ / \ / \ / \
0 1 2 3 4 5 6 7 8 9 10 11 12 13
Merkle tree authentication paths in binary rung strategy are
constructed from the perfect binary tree that a given rung covers.
For example, the authentication path for leaf 9 would include the
hash of leaf 8 and (10,11) which is sufficient to re-create rung
(8,11) which covers leaf 9.
The following table gives examples of ladders for values of N up to
19 to showcase how the rungs evolve as new messages are appended to a
given node set.
Kaizer, et al. Expires 22 April 2027 [Page 5]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
Number of Messages | Ladder Rungs
N |
-------------------------------------------------
1 | (0,0)
2 | (0,1)
3 | (0,1) (2,2)
4 | (0,3)
5 | (0,3) (4,4)
6 | (0,3) (4,5)
7 | (0,3) (4,5) (6,6)
8 | (0,7)
9 | (0,7) (8,8)
10 | (0,7) (8,9)
11 | (0,7) (8,9) (10,10)
12 | (0,7) (8,11)
13 | (0,7) (8,11) (12,12)
14 | (0,7) (8,11) (12,13)
15 | (0,7) (8,11) (12,13) (14,14)
16 | (0,15)
17 | (0,15) (16,16)
18 | (0,15) (16,17)
19 | (0,15) (16,17) (18,18)
Different rung strategies may result in rungs and authentication
paths that differ from the above. This document does not limit to
any specific rung strategy, although for interoperability in
constructing/evaluating authentication paths the current draft
assumes each rung is a perfect binary tree. Additional rung
strategies may be defined in updates to this draft or in future
drafts.
1.3.1. Related Work
The binary rung strategy appears under different names in other
cryptographic constructions based on Merkle trees. Champine defines
a binary numeral tree [BIN-NUM-TREES] with similar structure (the
successive perfect binary subtrees are called eigentrees). Other
similar Merkle tree-based constructions include Crosby and Wallach's
history trees [HISTORY-TREE], Todd's Merkle mountain ranges
[MERKLE_MOUNTAIN], and Reyzin and Yakoubov's cryptographic
accumulator [CRYPTO-ACC].
Kaizer, et al. Expires 22 April 2027 [Page 6]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
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.
The single pipe character, "|", is used to denote concatenation as is
done in [RFC4034].
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
The DNSKEY format MUST be the same as in
[I-D.westerbaan-dnssec-mldsa]. The Algorithm field of the DNSKEY RR
MUST be set to the value allocated for ML-DSA-44-MTL-SHAKE-128 (see
Section 8).
4. RRSIG Resource Records
The value of the signature field in the RRSIG RR consists of a
variable-length value starting with one-octet MTL-Type and followed
by MTL Authentication Data:
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 | |
+-+-+-+-+-+-+-+-+ |
| MTL Authentication Data |
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MTL-Type octet is provided for extensibility. In this
specification, the type MUST be set to full (0x01). The value 0x00
MUST NOT be used and is reserved for future use. Other
specifications may define additional types. The MTL Authentication
Data includes the signature information necessary to evaluate the MTL
response and is described in Section 5.1.
Kaizer, et al. Expires 22 April 2027 [Page 7]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
5. MTL Implementation Details
This section describes the data structures for the full MTL-Type in
Section 5.1, how to instantiate the hashing algorithms in
Section 5.2, and summarizes how this covers individual DNS RRsets in
Section 5.3. Taken together, it allows a signer or verifier to sign
and verify MTL DNSSEC signatures in a consistent, interoperable
manner. Appendix B and Appendix C include high-level steps a signer
or verifier could take to implement these concepts.
The octets required in this section are based on the values for ML-
DSA-44 as specified in [FIPS204] and could be different if other
underlying signature algorithms were supported.
5.1. Full Signatures
This section describes the format of the full MTL-Type Authentication
Data referred to in Section 4, also referred to as full signatures in
this document.
A full signature consists of two base components:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
| |
// Condensed Signature //
| (variable octets) |
+-------------------------------+
| |
// Signed Ladder //
| (variable octets) |
+-------------------------------+
Where:
* condensed_signature is described in Section 5.1.1
* signed_ladder is described in Section 5.1.2
5.1.1. Condensed Signatures
A condensed MTL signature contains a Merkle proof (authentication
path) and consists of:
Kaizer, et al. Expires 22 April 2027 [Page 8]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
| Flags (2-octets) |
+-------------------------------+
| |
// SID //
| (32-octets) |
+-------------------------------+
| |
// Randomizer //
| (16-octets) |
+-------------------------------+
| |
| Leaf Index |
| (8-octets) |
| |
+-------------------------------+
| |
| Target Rung Left Index |
| (8-octets) |
| |
+-------------------------------+
| |
| Target Rung Right Index |
| (8-octets) |
| |
+-------------------------------+
| Sibling Hash Count (2-octets) |
+-------------------------------+
| |
// Sibling Hash Values //
| (16-octets per sibling) |
+-------------------------------+
Where:
* flags, string providing future extensibility; it MUST be 0x0000 in
this document
* SID, series identifier of the node set
* randomizer, randomizer value associated with leaf_index
* leaf_index, the leaf index of the message being authenticated, a
non-negative integer between 0 and 2^64-1
* rung_left, the left index of the target rung, a non-negative
integer between 0 and 2^64-1
* rung_right, the right index of the target rung, a non-negative
integer between 0 and 2^64-1
Kaizer, et al. Expires 22 April 2027 [Page 9]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
* sibling_hash_count, the number of sibling hash values in the
authentication path, a non-negative integer between 0 and 2^16-1
* sibling_hashes, zero or more sibling hash values
The SID is RECOMMENDED to be generated from an approved Random Bit
Generator [RFC4086] and the randomizer MUST be generated from an
approved Random Bit Generator.
5.1.2. Signed Ladder
A signed ladder data structure consists of:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
| Flags (2-octets) |
+-------------------------------+
| |
// SID //
| (32-octets) |
+-------------------------------+
| Rung Count (2-octets) |
+-------------------------------+
| |
// Rung Data //
| (32-octets per rung) |
+-------------------------------+
| Underlying Signature Length |
| (4-octets) |
+-------------------------------+
| |
// Underlying Signature //
| (2420-octets) |
+-------------------------------+
Where:
* flags, string providing future extensibility; the initial value
for this field MUST be 0x0000
* SID, same value as defined in Section 5.1.1
* rung_count, the number of rungs in the ladder, a positive integer
between 1 and 2^16-1
* rungs, one or more rung data structures
* sig_len, the length in octets of the underlying signature on the
ladder, a positive integer between 1 and 2^32-1
* sig, the underlying signature on the ladder (i.e., flags, SID,
rung_count, and rungs)
Kaizer, et al. Expires 22 April 2027 [Page 10]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
The format of the sig MUST be the same as in
[I-D.westerbaan-dnssec-mldsa], however the message signed is the
ladder and not the data described in 3.1.8.1 of [RFC4034].
Each Rung Data consists of:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
| |
| Left Index |
| (8-octets) |
| |
+-------------------------------+
| |
| Right Index |
| (8-octets) |
| |
+-------------------------------+
| |
// Rung Hash Value //
| (16-octets) |
+-------------------------------+
Where:
* left_index, the left index of the rung, a non-negative integer
between 0 and 2^64-1
* right_index, the right index of the rung, a non-negative integer
between left_index and 2^64-1
* hash, the rung hash value
5.2. MTL Hash Function Instantiation
This document specifies the use of cSHAKE128 as the hash function for
use in MTL as defined in NIST SP 800-185 [CSHAKE]. For MTL the hash
algorithm is utilized to generate the Merkle tree(s) that comprise a
node set where the inputs to the hash function depend on whether the
node is a leaf node or internal node.
For a leaf node, LEAF = (SID | Randomizer | leaf_index |
len(ctx_msg) | ctx_msg | msg) where:
* SID, a 32-octet value as described in Section 5.1.1
* leaf_index, an 8-octet value denoting the leaf node's index
* Randomizer, a 16-octet value as described in Section 5.1.1
* len(ctx_msg), a 1-octet value of the length of the included
message-specific context string; MUST be 0x00 in this draft
Kaizer, et al. Expires 22 April 2027 [Page 11]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
* ctx_msg, variable length byte array
* msg, variable length byte array containing the message
corresponding to the leaf node, i.e., RRSIG_RDATA | RR(1) |
RR(2)...
The inclusion of ctx_msg is provided for future extensibility and
consistency with other recent specifications that support per-message
context strings.
For an internal node, INTERNAL = (SID | left_index | right_index |
hash_left | hash_right) where:
* SID, a 32-octet value
* left_index, an 8-octet value denoting the internal node's left
index
* right_index, an 8-octet value denoting the internal node's right
index
* hash_left, a 16-octet value denoting the left child hash
* hash_right, a 16-octet value denoting the right child hash
This is then applied to cSHAKE as follows to produce a cSHAKE128
output:
H_leaf = cSHAKE(LEAF, 128, "", HASH_CUSTOMIZATION_STRING_LEAF)
H_int = cSHAKE(INTERNAL, 128, "", HASH_CUSTOMIZATION_STRING_INT)
where HASH_CUSTOMIZATION_STRING_LEAF is the user customization string
input allowed by cSHAKE and MUST be an octet string represented by
"{'M','T','L','L','E','A','F'}" and HASH_CUSTOMIZATION_STRING_INT
MUST be an octet string represented by "{'M','T','L','I','N','T'}".
5.3. MTL Signature Coverage
MTL signatures protect the same DNS RRset responses as non-MTL DNSSEC
responses because the leaf nodes correspond to the same RRSIG_RDATA |
RR(1) | RR(2)... observed in 3.1.8.1 of [RFC4034]. The primary
difference is how this is covered by the full MTL-Type signature
related data as described next.
A full MTL-Type signature signs a ladder rather than individual DNS
RRsets, i.e., signature = sign(FLAGS | SID | RUNG_COUNT | RUNG_DATA).
Meanwhile, the msg input to the leaf node hash operation contains the
[RFC4034] data. This enables one signature on a signed ladder to
authenticate every RRset included in that ladder rather than signing
each RRset individually.
Kaizer, et al. Expires 22 April 2027 [Page 12]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
A condensed signature does not provide a signature using sign(...)
but provides enough information to prove inclusion in a Merkle tree
node set covered by a signed ladder. The association with a full
signature that has sign(...) data covers the condensed signature.
6. Algorithm Numbers for DS, DNSKEY, and RRSIG Resource Records
The algorithm number associated with the use of ML-DSA-44-MTL-
SHAKE-128 in DS, DNSKEY, and RRSIG resource records is TBD. This
registration is fully defined in the IANA Considerations section.
7. Implementation Considerations
7.1. Batch Signing
Signing RRsets in batches, i.e., as multiple additions to a node set,
rather than as individual additions or as messages can leverage MTL
to reduce the number of signature and verification operations
performed with the underlying signature algorithm. This results in
reducing the average computational overhead per message signed/
verified. This practice can also reduce the load on a hardware
security module. Batches also benefit the verifier by reducing the
number of full signatures required for validation because multiple
RRSIGs can be verified by the signed ladder covering a batch. The
appropriate batch size will depend on the properties of the zone and
the requirements of the zone operator. Batch size needs to be
considered carefully to ensure that new signatures are available in a
timely manner while still gaining the benefits of batch signing
[MTL-ENDURANCE].
7.2. Online Signing
MTL can accommodate online signing, also known as dynamic signing,
where responses are generated dynamically at query time. How exactly
this is achieved is dependent on the operator's requirements. One
example, but not limiting, is to generate a new MTL node set for each
query response. Implementors should be aware that online signing may
limit the amortization benefits of MTL to only data within the same
query.
7.3. Client Optimizations with Signed Ladders
In MTL the same signed ladder may be encountered frequently because
it covers many underlying RRsets. Clients interested in optimizing
performance can track validated signed ladders separately, e.g., in a
signed ladder cache. Once tracked, a client does not need to re-
validate the same signed ladder included in other RRSIGs.
Separately, a client could replace references to the signed ladder in
Kaizer, et al. Expires 22 April 2027 [Page 13]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
the RRSIG with a reference to the cached ladder so the same signed
ladder would only need to be stored once. These optional
optimizations can provide clients with storage, memory, and compute
related benefits in exchange for tracking signed ladder state.
8. IANA Considerations
8.1. DNSSEC Algorithm Number
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 (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:
+--------------+--------------------------------+
| Number | TBD |
| Description | ML-DSA-44-MTL-SHAKE-128 |
| Mnemonic | MLDSA44MTLSHAKE128 |
| Zone Signing | Y |
| Trans. Sec. | * |
| Reference | This specification |
+--------------+--------------------------------+
* There has been no determination of standardization of the use of
these algorithms with Transaction Security.
8.2. MTL Type Registry
IANA is requested to create a new subregistry in the "Domain Name
System Security (DNSSEC) Algorithm Numbers" registry as follows:
Registry Name: DNSSEC MTL Type Parameters Registration Procedure:
Specification Required Reference: [this document]
Kaizer, et al. Expires 22 April 2027 [Page 14]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
+===========+================+==========+=================+
| Value | Description | Mnemonic | Reference |
+===========+================+==========+=================+
| 0x00 | Reserved | | [this document] |
+-----------+----------------+----------+-----------------+
| 0x01 | Full Signature | FULL_SIG | [this document] |
+-----------+----------------+----------+-----------------+
| 0x02-0xF0 | Unassigned | | |
+-----------+----------------+----------+-----------------+
| 0xF1-0xFE | Private Use | N/A | [this document] |
+-----------+----------------+----------+-----------------+
| 0xFF | Reserved | | [this document] |
+-----------+----------------+----------+-----------------+
Table 1: DNSSEC MTL Type Parameters Registry
Designated experts reviewing requests for new MTL Type value should
verify that the referenced specification clearly defines the encoding
and processing of the new type, including how clients that do not
recognize the new type are expected to behave, and that the new type
does not duplicate the function of an existing registered value.
RFC Editor: please replace "[this document]" with the RFC number of
this document and remove this note.
9. 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.
Kaizer, et al. Expires 22 April 2027 [Page 15]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
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".
For testing purposes, ML-DSA-44-MTL-SHAKE-128 has been implemented in
the following DNS open-source applications:
* LDNS for key generation, zone signing, and zone verification with
MTL: https://github.com/Verisign/mtl-mode-ldns
* NSD authoritative name server with MTL:
https://github.com/verisign/mtl-mode-nsd
* Unbound recursive resolver with MTL: https://github.com/Verisign/
mtl-mode-unbound
These implementations depend on the reference implementation of MTL
which is available in C. The MTL library can be found at
https://github.com/Verisign/MTL.
10. Security Considerations
The security considerations of [FIPS204] and
[I-D.westerbaan-dnssec-mldsa] are inherited in the usage of ML-DSA-
MTL in DNSSEC.
ML-DSA-44-MTL-SHAKE-128 is 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 and
comparable to non-PQC DNSSEC algorithms such as ECDSAP256SHA256
(algorithm 13). Future documents may describe ML-DSA-65 or ML-DSA-87
if stronger security levels are needed.
A private key used for DNSSEC MUST NOT be used for other purposes.
Otherwise, cross-protocol or cross-application attacks are possible.
Implementers MUST NOT use the same SID for multiple MTL
instantiations, e.g., the MTL instantiation for a KSK node set and
the MTL instantiation for a ZSK node set MUST use different SIDs to
provide cryptographic separability.
Post-quantum algorithms in DNSSEC may introduce larger keys,
signatures, and/or signing/verifying effort which may lead to
differences in resource capacity compared to existing DNS operational
profiles. Accounting for such factors will help mitigate potential
resource exhaustion attacks. The following highlights such factors
as it relates to ML-DSA in MTL:
Kaizer, et al. Expires 22 April 2027 [Page 16]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
* ML-DSA signatures will require more space to store in both
authoritative and caching resolvers; while condensed signatures
help address this challenge at least one full ML-DSA signature
will be needed.
* Additional TCP traffic compared to non-PQC DNSSEC algorithms is
expected. Full MTL-Type responses in this draft will always
exceed DNS over UDP.
* Clients concerned about re-tries, e.g., a UDP query being
truncated and then re-attempted over TCP, are RECOMMENDED to
perform all queries over TCP when encountering a zone signed with
ML-DSA-44-MTL-SHAKE-128.
* Signing and verifying times in ML-DSA are competitive with
existing non-PQC DNSSEC algorithms. Even so, clients should test
their system's capacity to handle full signature responses signed
with ML-DSA.
11. Acknowledgements
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.
12. References
12.1. Normative References
[FIPS204] National Institute of Standards and Technology (NIST),
"Module-Lattice-Based Digital Signature Standard", FIPS
PUB 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024,
<https://doi.org/10.6028/NIST.FIPS.204>.
[I-D.westerbaan-dnssec-mldsa]
Westerbaan, B. and S. Schmieg, "Module-Lattice Digital
Signature Algorithm for DNSSEC", Work in Progress,
Internet-Draft, draft-westerbaan-dnssec-mldsa-04, 11
August 2026, <https://datatracker.ietf.org/doc/html/draft-
westerbaan-dnssec-mldsa-04>.
[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>.
Kaizer, et al. Expires 22 April 2027 [Page 17]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
[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>.
[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>.
12.2. Informative References
[BIN-NUM-TREES]
Champine, L., "Streaming Merkle Proofs within Binary
Numeral Trees", Cryptology ePrint Archive Paper 2021/038,
2021, <https://eprint.iacr.org/2021/038>.
[CRYPTO-ACC]
Reyzin, L. and S. Yakoubov, "Efficient data structures for
tamper-evident logging", Zikas, V., De Prisco, R. (eds)
Security and Cryptography for Networks SCN 2016, LNCS,
vol. 9841, pp. 292-309. Springer, Cham, 2016,
<https://doi.org/10.1007/978-3-319-44618-9_16>.
[CSHAKE] National Institute of Standards and Technology (NIST),
"DSHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and
ParallelHash", FIPS SP 800-185,
DOI 10.6028/NIST.SP.800-185, 22 December 2016,
<https://doi.org/10.6028/NIST.SP.800-185>.
[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.
[HISTORY-TREE]
Crosby, S. and D. Wallach, "Efficient data structures for
tamper-evident logging", Proceedings of the 18th USENIX
Security Symposium pp. 317-334. USENIX Association (2009),
<https://dl.acm.org/doi/abs/10.5555/1855768.1855788>.
[I-D.sheth-pqc-dnssec-strategy]
Sheth, S., Chung, T., and B. Overeinder, "Post-Quantum
Cryptography Strategy for DNSSEC", Work in Progress,
Internet-Draft, draft-sheth-pqc-dnssec-strategy-02, 16
October 2026, <https://datatracker.ietf.org/doc/html/
draft-sheth-pqc-dnssec-strategy-02>.
Kaizer, et al. Expires 22 April 2027 [Page 18]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
[MERKLE_MOUNTAIN]
Todd, P., "Merkle Mountain Ranges",
<https://github.com/opentimestamps/opentimestamps-
server/blob/master/doc/merkle-mountain-range.md>.
[MTL-ENDURANCE]
Tran, M. and T. Chung, "Randomized Evaluation of SLH-DSA-
MTL's Impact on Reducing PQ-DNSSEC Signature Sizes", 18
March 2025, <https://github.com/IQTF/pq-dnssec-
materials/raw/refs/heads/main/IETF122/
Tran_Randomized_evaluation_of_SLH-DSA-
MTL's_impact_on_reducing_PQ-DNSSEC_signature_sizes.pdf>.
[MTL-MODE] Fregly, A., Harvey, J., Kaliski, B., and S. Sheth, "Merkle
Tree Ladder Mode: Reducing the Size Impact of NIST PQC
Signature Algorithms in Practice", in Rosulek, M.
(editor), Lecture Notes in Computer Science VOLUME 13871,
CT-RSA 2023 - Cryptographers Track at the RSA
Conference pages 415-441,
DOI 10.1007/978-3-031-30872-7_16, 2023,
<https://eprint.iacr.org/2022/1730.pdf>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
Appendix A. Change Log
00: Initial draft of the document.
01: Removed EDNS(0) option and specified full MTL-Type responses
are the only response type for every RRset. Future drafts may
define other types that leverage the same MTL data structures and
wire format.
02: Updated document track, added IANA registry for MTL Types
03: Added client optimization consideration, re-ordered appendix
steps to optimize order
Appendix B. Signer Steps
A signer, e.g., an authoritative server, performs the following set
of operations to sign messages in MTL.
Kaizer, et al. Expires 22 April 2027 [Page 19]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
The first step is performed once per key pair:
1. Generate a public / private key pair for ML-DSA-44, e.g., for use
as a KSK or ZSK.
The second step is performed once per node set to be signed:
2. Generate a series identifier (SID) for the node set and
initialize a node set for the series. The counter of the node
set is set to 0 in this step.
The third and fourth steps are performed once per message to be
signed in a node set:
3. Sample a randomizer and compute the leaf hash for the message.
4. Append the leaf hash to the node set. The counter of the node
set is incremented in this step.
The fifth and sixth steps are performed whenever the signer wants to
produce a new signed ladder. The signer could do so after each new
message is added, or after a new batch of new messages is added.
5. Compute the current ladder for the node set using one or more
rungs that collectively authenticate all the nodes in the node
set.
6. Sign the ladder using the ML-DSA-44 private key generated in (1).
The seventh step is performed whenever the signer wants to provide a
full signature to a requester, e.g., upon receiving a DNS query.
7. Provide the full signature as described in Section 5.1.
The eighth step is performed whenever the signer wants to compute a
new authentication path for a message relative to the current ladder.
The signer could do so after each new message is added, after a batch
of new messages is added, and/or later, as needed, to update the
authentication paths for older messages so that they are relative to
the current ladder.
8. Compute an authentication path for the message at a specified
message index relative to the current ladder.
Appendix C. Verifier Steps
A verifier, e.g., a DNSSEC-aware resolver, performs the following to
verify signatures in MTL:
Kaizer, et al. Expires 22 April 2027 [Page 20]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
1. Obtain the signer's public key, e.g., from appropriate DNSKEY
records.
The following steps are performed as needed for each full MTL-Type
response to be authenticated:
2. From the condensed signature, obtain the authentication path
(i.e., sibling hash values) and the SID.
3. Compute a leaf hash from the message as described in Section 5.2.
4. Verify the authentication path and leaf hash relative to the
compatible rung found in the ladder.
5. Validate the included signed ladder signature against the public
key in (1).
The order of 2-5 is such that a client validates the fast hash
related checks first. If these checks fail, the client can avoid the
potentially expensive PQ signature check.
Authors' Addresses
A. Kaizer
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: akaizer@verisign.com
URI: https://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/
B. Kaliski
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: bkaliski@verisign.com
URI: https://www.verisignlabs.com/
Kaizer, et al. Expires 22 April 2027 [Page 21]
Internet-Draft ML-DSA-MTL-DNSSEC October 2026
S. Sheth
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: ssheth@verisign.com
URI: https://www.verisignlabs.com/
Kaizer, et al. Expires 22 April 2027 [Page 22]