]>
Stateful Hashbased Signatures For DNSSEC
Verisign Labs
12061 Bluemont Way
Reston
VA
20190
USA
afregly@verisign.com
http://www.verisignlabs.com/
DACS group, EEMCS, University of Twente
DRIENERLOLAAN 5
ENSCHEDE
7522 NB
NL
r.m.vanrijswijk@utwente.nl
https://people.utwente.nl/r.m.vanrijswijk
Applications
DNSOP Working Group
DNSSEC
Stateful
Signature
Algorithm
This document describes how to use stateful hashbased signature schemes (SHBSS) with the DNS Security Extensions (DNSSEC). The schemes include the Hierarchical Signature System (HSS) variant of LeightonMicali HashBased Signatures (HSS/LMS), the eXtended Merkle Signature Scheme (XMSS), and XMSS MultiTree (XMSS^MT). In addition, DNSKEY and RRSIG record formats for the signature algorithms are defined and new algorithm identifiers are described.
The Domain Name System Security Extensions (DNSSEC), which are broadly defined in , , and , use cryptographic keys and digital signatures to provide data origin authentication and data integrity in the DNS. Popular digital signature algorithms currently required or recommended for DNSSEC include RSA , the Elliptic Curve Digital Signature Algorithm (ECDSA) and the EdwardsCurve Digital Security Algorithm (EdDSA) .
This document describes how to use the following signature algorithms with DNSSEC:
 Hierarchical Signature System/LeightonMicali HashBased Signatures (HSS/LMS)
 eXtended Merkle Signature Scheme (XMSS)
 XMSS MultiTree (XMSS^MT)
In addition, algorithm identifiers, DNSKEY record formats and RRSIG record formats are defined. The public key, signature and hash lengths specified herein are based on algorithm parameters that specify 32byte hashes. This length provides a desired minimum 128bit security level. Use of algorithm parameters specifying hashes of lengths other than 32 will result in public key and signature lengths that differ from the lengths specified herein.
This document covers multitree variants of both LMS (HSS/LMS) and XMSS (XMSS^MT). The single tree XMSS variant is also covered as XMSS^MT does not provide for a single tree.
HSS/LMS, XMSS and XMSS^MT are variants of Merkle Tree Signatures . The multitree structures of HSS/LMS and XMSS^MT are optimized for incremental onetime key pair generation, where the desired number of onetime key pairs and signatures would make pregeneration of all onetime key pairs impractical using a single tree structure. HSS/LMS, XMSS and XMSS^MT also provide other optimizations such as those enabled by use of the Winternitz onetime signature scheme .
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.
Double pipe characters, "" are used in this document in definitions of public keys 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).
Algorithms used in DNSSEC are identified by mnemonic identifiers and corresponding numeric identifiers that are registered in . Per , the Algorithm field of DNSKEY RRs is a numeric identifier that identifies the public key's cryptographic algorithm and determines the format of the Public Key field. The mnemonic algorithm identifiers proposed herein for HSS/LMS, XMSS and XMSS^MT are "HSSLMS", "XMSS", and "XMSSMT" respectively. These identifiers are proposed for adoption into in the IANA Consideration section of this document. It is anticipated that corresponding numeric identifiers will be assigned by IANA when the algorithms are registered into . Placeholder numeric identifiers are defined herein for use in examples .
The DNSKEY HSS/LMS Public Key field consists of a 60octet value of an HSS/LMS public key generated using one of the parameter sets associated with the HSS/LMS algorithm and identified in the IANA "LeightonMicali Signatures (LMS)" registry of . The public key of the HSS/LMS scheme consists of a concatenation of a 4octet value L specifying the number of tree levels, followed by the elements of the public key for the toplevel tree in the HSS/LMS tree hierarchy. The DNSKEY HSS/LMS Public Key field can be described as:
where LMS_PUBLIC_KEY can be described as:
where the elements are defined as follows:
 L: An unsigned 4octet value specifying the number of tree levels in the HSS/LMS tree hierarchy
 LMSType: A 4octet identifier for the public key hashing algorithm and Merkle tree parameters where the identifier MUST match a Numeric Identifier for an algorithm Name listed in the "LeightonMicali Signatures (LMS)" registry of [LMSREGISTRY].
 LMSOTSType: A 4octet identifier for the onetime signature (OTS) hashing algorithm and parameters where the identifier MUST match a Numeric Identifier for an algorithm Name listed in the "LMSOTS Signatures" registry of [LMSREGISTRY].
 I: A 16octet value that is the private key identifier; according to Section 5.3 of [RFC8554], I is the value used for all computations for the same LMS tree, which in the case of the public key is the toplevel Merkle Tree.
 T[1]: The hash that is the root node for the top level Merkle Tree and which serves as the public key. The length of the hash is defined based on the algorithm identified with the LMSType field and will be at least 32 octets
The values of the LMSType and LMSOTSType elements MUST specify algorithms that create hashes with a length of at least 32 octets. Given the minimum hash length of 32 octets, an HSS/LMS public key field will have a minimum length of 60 octets.
The DNSKEY public key field of XMSS and XMSS^MT resource records consists of an XMSS or XMSS^MT public key generated using a parameter set listed in . The DNSKEY XMSS Public Key field and the XMSS^MT Public Key field can both be described as:
where the elements are defined as follows:

OID: A 4octet Object Identifier (OID) for the algorithm type where OID identifies a signature algorithm applicable to either the XMSS or XMSS^MT registry in and where the algorithm number field of the DNSKEY RR determine which registry is applicable. OID MUST match a Numeric Identifier for an Algorithm Name listed in the applicable registry in as identified by the algorithm number field of the DNSKEY RR.

T[1]: An noctet root node hash from the toplevel Merkle Tree where "n" is determined based on the algorithm type and MUST be at least 32.

Seed: An noctet seed where "n" is determined based on algorithm type and MUST be at least 32.
The total combined height of the tree levels and the number of tree levels in an XMSS^MT tree hierarchy are determined based on the “h/d” elements of the algorithm names where "h" is the total combined height and "d" is the number of tree levels in the tree hierarchy. All trees in an XMSS^MT tree hierarchy MUST be of height h/d per section 4.2. of .
The value of "n" for the length of the root node hash and the seed MUST be equal and at least 32. The set of allowable OIDs is therefore limited to algorithm types that use a value of 32 or more for "n". The length of the DNSKEY public key field can be determined based on the value of "n". The minimum length of the DNSKEY Public key field is 68 octets based on the minimum allowable value for "n" being 32.
HSS/LMS signatures consist of a sequence of octet values whose length is dependent on the specific algorithm parameters used when creating the signature. Signatures are encoded into the Signature field of an RRSIG resource record as a simple octet string. HSS/LMS signatures are composed of elements, as described in 6.2. of , and MUST be generated with an algorithm consistent with 6.2. of .
HSS/LMS signature lengths are determined based on parsing an HSS/LMS signature and determining parameters associated with the LMSType and LMSOTSType elements found in the signatures as illustrated in "Test Case 1 Signature" in Appendix F of . The LMSType and LMSOTSType elements of the Public Key Field of the DNSKEY RR MUST match the LMSType and LMSOTSType for the toplevel tree in the HSS/LMS tree hierarchy. Table 1 of illustrates LMSOTS signature lengths for various algorithm parameter sets. Table 3 of illustrates HSS signature lengths for various algorithm parameter sets.
HSS/LMS signature verification is performed using an algorithm functionally equivalent to 6.3. of [RFC8554]. A signature is verified if the final hash calculated by the verification algorithm matches the public key found in the DNSKEY RR applicable to the signature.
XMSS and XMSS^MT signatures consist of a sequence of octet values whose length is dependent on the specific algorithm parameters used when creating the signature. Signatures are encoded into the Signature field of an RRSIG resource record as a simple octet string. XMSS signatures are composed of elements as described in 4.1.8. of and MUST be generated using an algorithm consistent with 4.1.9. of . XMSS^MT signatures are composed of elements as described in 4.2.3. of [RFC8391] and MUST be generated using an algorithm consistent with 4.2.4. of .
XMSS and XMSS^MT signature lengths are determined based on parameters associated with the XMSS or XMSS^MT algorithm identified in by the OID element of the public key field of the DNSKEY RR associated with the signature and with the Winternitz parameter implicitly set to 16 per 5.2. of . Parameters corresponding to an OID are defined as elements of algorithm names corresponding to an OID as illustrated in Table 2 and Table 4 of . Table 3 and Table 5 of illustrate signature lengths for various algorithm parameter sets.
XMSS signature verification is performed using an algorithm functionally equivalent to 4.1.10. of . XMSS^MT signature verification is performed using an algorithm functionally equivalent to 4.2.5. of . A signature is verified if the final hash calculated by the verification algorithm matches the public key found in the DNSKEY RR applicable to the signature.
HSS/LMS, XMSS and XMSS^MT implementations for DNSSEC MUST be implemented in conformance with and . Implementations subject to MUST be implemented in conformance with . The specifications of the algorithms herein (signature format and public key format) are intended to be “compatible” with the uses of the same algorithms in other protocols. Even though algorithm identifiers may vary by protocol (DNSSEC registry here, object identifier in CMS), the cryptographic inputs, operations and outputs are the same. Implementations therefore SHOULD be interoperable with algorithm implementations for other IETFdefined protocols such that the same cryptographic libraries may be used across protocols. In addition to being specified herein, HSS/LMS has been specified in "Use of the HSS/LMS HashBased Signature Algorithm in the Cryptographic Message Syntax (CMS)" and in "Use of the HSS/LMS HashBased Signature Algorithm with CBOR Object Signing and Encryption (COSE)". XMSS and XMSS^MT are not currently specified for use in any protocols defined by IETF RFCs.
Algorithm numbers in DNSKEY records are specific to DNSSEC and are registered in .
Both XMSS and XMSS^MT are covered herein due to several factors. XMSS^MT does not have a single tree level variant and therefore XMSS is included for implementations that may wish to use a single Merkle tree. Providing for both variants is also important because limiting choice to the parameter sets for XMSS^MT would result in less optimal tree and proof sizes for some implementations. This contrasts with covering just HSS/LMS. LMS is not covered because HSS/LMS provides for a single level Merkle tree with minimal overhead compared to a single level LMS tree. This overhead consists of an extra four bytes in both RRSIG RRs and DNSKEY RRs.
The hierarchical tree structures of HSS/LMS and XMSS^MT allow subordinate trees to be generated when needed. This provides flexibility as the entire multitree does not need to be generated at one time. This also supports distributed generation of subordinate trees and distributed signing operations using distributed subordinate trees. Distributing tree generation and signing provides for fault tolerance and scalability that may be desirable based on zone characteristics and operational requirements.
Signatures from multilevel hierarchical tree structures are larger than signatures from single tree structures capable of generating the same number of signatures. This is primarily due to OTS signatures from each level in the hierarchy being included in the signature whereas a signature for a single tree with a height equal to the cumulative height of a tree hierarchy will only have a single OTS signature included in the signature.
Public keys MUST be created with a hash algorithm providing at least a 128bit security level. Algorithms for HSS/LMS MUST be selected from the "LeightonMicali Signatures (LMS)" registry . Algorithms for XMSS and XMSS^MT MUST be selected from either the "XMSS Signatures" or "XMSS^MT Signatures" registries found in .
The larger signature sizes of HSS/LMS, XMSS and XMSS^MT will result in DNS responses that are too big to fit within typical UDP MTUs, due to the size of the included RRSIG RRs. While EDNS(0) makes it possible to transport larger responses that exceed MTUs, implementers often try to avoid the resulting fragmentation , . In the absence of EDNS(0), or in case the size of a response exceeds the maximum accepted size, as indicated in EDNS(0) parameters, DNS responses over UDP will be truncated and the requester will be asked to query again over TCP as described in 4. of .
The time needed for key generation and zone signing with stateful hashbased signature algorithms may vary significantly based on the parameter sets chosen for the algorithm per 6.4. of and 5.4.1 of with this having operational impact.
Methods for addressing the abovedescribed operational considerations are not within the scope of this document and should be addressed in additional documents.
The examples illustrate HSS/LMS and XMSS^MT public keys and signatures applicable to the example MX RR illustrated below. The example public keys may be used to verify the example signatures. The example signatures were generated with the example OTS private keys.
The signature examples below are applicable to the following example MX record:
To facilitate creation of the examples, dummy IANA DNSSEC algorithm identifiers are used. There is no intention that these algorithm identifiers have any applicability other than for their use in the examples, as future algorithm identifiers assigned by IANA may be different than those used in the examples. Any overlap of these identifiers with existing or planned IANA algorithm identifiers is unintentional and not meant to supersede the existing or planned identifier assignments. The algorithm identifiers used herein have the following values:
A ZSK for a zone is used to sign RRsets within the zone, producing RRSIG RRs containing ZSK signatures on the RRsets. The RRSIG RRs link the RRsets into the DNSSEC verification chain and provide for verifying RRsets based on verification of the ZSK signatures. Further details on DNSSEC verification can be found in , and .
The OTS keys used in creating the example signatures are provided as examples. They may be used for generating OTS signatures on the example MX RR that should match the example OTS signatures.
DNSKEY RR for ZSK in Presentation Format:
OTS Private Key Used in Signature Example in base64:
The Public Key field of the example HSS/LMS ZSK is broken out in hexadecimal below to provide a more readable illustration of the elements of an HSS/LMS Public Key Field.
This example RRSIG corresponds to the example HSS/LMS public key. It has an OTS signature on an MX RRset comprised of the example MX RR. The OTS signature on the MX RRset was generated using the example HSS/LMS ZSK OTS private key illustrated above. In wire format, the signature is 2908 octets in length.
The signature field of the example HSS/LMS RRSIG RR is broken out in hexadecimal below to provide a more readable illustration of the elements of an HSS/LMS signature.
OTS Private Key used for the example signature below in base64:
DNSKEY RR in Presentation Format:
The Public Key field of the example XMSS^MT ZSK is broken out in hexadecimal below to provide a more readable illustration of the elements of an HSS/LMS Public Key Field.
This example RRSIG corresponds to the example XMSS^MT public key. It has
an OTS signature on an MX RRset comprised of the example MX RR. The OTS
signature on the MX RRset was generated using the example XMSS^MT ZSK OTS
private key illustrated above. In wire format the signature would be 4963
octets in length.
The signature field of the example XMSS^MT RRSIG RR is broken out in hexadecimal below to provide a more readable illustration of the elements of an XMSS^MT signature.
This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entries are requested to be added to the registry:
* There has been no determination of standardization of the use of these algorithms with Transaction Security.
and are IANA registries in which additional algorithm identifiers may be registered in the future for use with HSS/LMS, XMSS and XMSS^MT.
This document refers to allowable HSS/LMS algorithm signature identifiers. These identifiers are found in the IANA “Leighton Micali Signatures (LMS)" registry .
HSS/LMS refers to allowable LMS OTS algorithm signature identifiers. These identifiers are found in the IANA “LMOTS Signatures” registry .
This document refers to allowable XMSS and XMSS^MT algorithm signature identifiers. These identifiers are found in the IANA “XMSS Signatures” and “XMSS^MT Signatures” registries . Separate algorithm identifiers for XMSS and XMSS^MT are needed so that the appropriate registry in is identified for matching OIDs to algorithm parameter sets.
XMSS and XMSS^MT use a set of allowable XMSS OTS signature algorithms. Identifiers for allowable algorithms (WOTS+ signatures) are found in the IANA “WOTS+ Signatures” registry .
NOTE: Please remove this section and the reference to RFC 794 prior to publication as an RFC.
There are currently no implementations available for public examination
HSS/LMS, XMSS and XMSS^MT as defined here MUST use 256bit or larger hash algorithms. 256bit hash sizes are consistent with a desired minimum 128bit security level for HSS/LMS, XMSS and XMSS^MT per .
The HSS/LMS public key MUST be generated in conformance with Section 4 of .
The XMSS public key for a single level tree structure or a XMSS^MT hierarchical tree structure generated by a single computing device ("cryptographic module") MUST be generated in conformance with processing steps described in section 5 of .
Implementations MUST use the same hash algorithm for hashes in all nodes within a Merkle Tree or Merkle Tree hierarchy.
OTS private keys MUST NOT be used more than once for signing. This requirement is needed as reuse of OTS private keys may provide an attacker with key information that enables forging of signatures. A detailed discussion of the vulnerabilities reuse of OTS private keys enables is described in .
The requirement that OTS private keys may only be used once creates the need for state management to assure OTS keys are not reused. This can be a challenge as state needs to be maintained in case of system failure and also across distributed implementations. This challenge is increased for DNSSEC implementations that perform dynamic signing.
Seeds and random numbers used in key generation and for hashing SHOULD be generated in accordance with 6.1 and 6.2 of .
The requirements in this section apply to implementations subject to .
OTS private keys for hashbased algorithms MUST NOT be exported from a cryptographic module. In adherence to this operational constraint, OTS private keys for individual subtrees in a hierarchical Merkle Tree structure including the toplevel tree MUST be generated, stored and used within a single cryptographic module and MUST NOT be exported.
In NIST provides guidance and requirements for multitree hashbased algorithms implemented across distributed "cryptographic modules". Per 7.2. of , these implementations require minor changes to XMSS^MT, and no changes to HSS/LMS. XMSS^MT Implementations which distribute trees across cryptographic modules and which are subject to therefore MUST use the algorithms specified in 7.2. of . NIST’s approach is to have the cryptographic modules for each tree level simply implement a singletree signature scheme, with the signer combining the outputs of the different cryptographic modules into a multilevel signature, without further cryptographic processing.
Seeds and random numbers used in key generation and for hashing MUST be generated in accordance with 6.1 and 6.2 of .
The authors would like to acknowledge the following individuals for their contributions to the development of this document: Dave Blacka, Jim Goodman, James Gould, Joseph Harvey, Scott Hollenbeck, Russ Housley, Burt Kaliski, Swapneel Sheth, Sean Turner, Duane Wessels
&RFC2119; &RFC4033; &RFC4034; &RFC4035; &RFC8174; &RFC8391; &RFC8554;
Domain Name System Security (DNSSEC) Algorithm Numbers
IANA
LeightonMicali Signature (LMS)
IANA
SP 800171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
National Institute of Standards and Technology (NIST)
SP 800208 Recommendation for Stateful HashBased Signature Schemes
National Institute of Standards and Technology (NIST)
XMSS: Extended HashBased Signatures
IANA
&RFC5702; &RFC6605; &RFC7766; &RFC8080; &RFC8624; &RFC8708; &RFC8778;
Fragmentation Avoidance in DNS
LeightonMicali HashBased Signatures in the Quantum RandomOracle Model
Cryptology ePrint Archive, Report 2017/607
DNS Flag Day 2020
ISC.org
WOTS+  Shorter Signatures for HashBased Signature Schemes
Lecture Notes in Computer Science, Volume 7918, Progress in Cryptology  AFRICACRYPT
Secrecy, Authentication, and Public Key Systems
Information Systems Laboratory, Stanford University
Technical Report No. 19791
A Certified Digital Signature
Information Systems Laboratory, Stanford University
Advances in Cryptology  CRYPTO '89, 9th Annual International Cryptology Conference
"Oops, I Did It Again"  Security of OneTime Signatures Under TwoMessage Attacks
SAC 2017. SAC 2017. Lecture Notes in Computer Science, vol 10719. Springer, Cham.
The SPHINCS+ Signature Framework
Cryptology ePrint Archive, Report 2019/1086