DNSOP Working Group A.M. Fregly Internet-Draft Verisign Labs Intended status: Standards Track R. van Rijswijk-Deij Expires: 3 September 2022 DACS group, EEMCS, University of Twente 2 March 2022 Stateful Hash-based Signatures For DNSSEC draft-afrvrd-dnsop-stateful-hbs-for-dnssec-00 Abstract This document describes how to use stateful hash-based signature schemes (SHBSS) with the DNS Security Extensions (DNSSEC). The schemes include the Hierarchical Signature System (HSS) variant of Leighton-Micali Hash-Based Signatures (HSS/LMS), the eXtended Merkle Signature Scheme (XMSS), and XMSS Multi-Tree (XMSS^MT). In addition, DNSKEY and RRSIG record formats for the signature algorithms are defined and new algorithm identifiers are described. 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 3 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 1] Internet-Draft Stateful HBS for DNSSEC March 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 4 3.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 4 3.2. HSS/LMS DNSKEY Resource Records . . . . . . . . . . . . . 5 3.3. XMSS and XMSS^MT DNSKEY Resource Records . . . . . . . . 6 4. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . 7 4.1. HSS/LMS RRSIG Resource Records . . . . . . . . . . . . . 7 4.2. XMSS and XMSS^MT RRSIG Resource Records . . . . . . . . . 7 5. Implementation Considerations . . . . . . . . . . . . . . . . 8 5.1. Interoperability Across Implementations . . . . . . . . . 8 5.2. Trade-offs of Hierarchical Trees . . . . . . . . . . . . 9 5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Operational Considerations . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Examples Scope . . . . . . . . . . . . . . . . . . . . . 10 6.2. Example Scenario . . . . . . . . . . . . . . . . . . . . 10 6.3. HSS/LMS Examples . . . . . . . . . . . . . . . . . . . . 11 6.3.1. HSS/LMS ZSK . . . . . . . . . . . . . . . . . . . . . 11 6.3.2. HSS/LMS ZSK Public Key Field Elements in Hexadecimal . . . . . . . . . . . . . . . . . . . . . 11 6.3.3. HSS/LMS RRSIG on the example MX RR in Presentation Format . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.4. HSS/LMS RRSIG on the example MX RR with Elements of Signature Broken Out in Hexadecimal . . . . . . . . . 13 6.4. XMSS^MT Examples . . . . . . . . . . . . . . . . . . . . 16 6.4.1. XMSS^MT ZSK . . . . . . . . . . . . . . . . . . . . . 17 6.4.2. XMSS^MT ZSK Public Key Field Elements in Hexadecimal . . . . . . . . . . . . . . . . . . . . . 17 6.4.3. XMSS^MT RRSIG on the example MX record in Presentation Format . . . . . . . . . . . . . . . . . . . . . . . 17 6.4.4. XMSS^MT RRSIG on the example MX Record with Elements of Signature Broken Out in Hexadecimal . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 2] Internet-Draft Stateful HBS for DNSSEC March 2022 9.1. Guidelines for Secure Use of Hash-Based Signature Algorithms . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. NIST SP 800-208 Compliance . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Normative References . . . . . . . . . . . . . . . . . . . . 26 12. Informative References . . . . . . . . . . . . . . . . . . . 28 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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. Popular digital signature algorithms currently required or recommended for DNSSEC [RFC8624] include RSA [RFC5702], the Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605] and the Edwards-Curve Digital Security Algorithm (EdDSA) [RFC8080]. This document describes how to use the following signature algorithms with DNSSEC: * Hierarchical Signature System/Leighton-Micali Hash-Based Signatures (HSS/LMS) [RFC8554] * eXtended Merkle Signature Scheme (XMSS) [RFC8391] * XMSS Multi-Tree (XMSS^MT) [RFC8391] In addition, algorithm identifiers, DNSKEY record formats and RRSIG record formats are defined. The public key, signature and hash lengths specified here-in are based on algorithm parameters that specify 32-byte hashes. This length provides a desired minimum 128-bit 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 here-in. This document covers multi-tree 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. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 3] Internet-Draft Stateful HBS for DNSSEC March 2022 HSS/LMS, XMSS and XMSS^MT are variants of Merkle Tree Signatures [MERKLE1979]. The multi-tree structures of HSS/LMS and XMSS^MT are optimized for incremental one-time key pair generation, where the desired number of one-time key pairs and signatures would make pre- generation of all one-time 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 one-time signature scheme [MERKLE1989][HUELSING13]. 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 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). 3. DNSKEY Resource Records 3.1. Algorithm Identifiers Algorithms used in DNSSEC are identified by mnemonic identifiers and corresponding numeric identifiers that are registered in [DNSSECREGISTRY]. Per [RFC4034], 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 here-in for HSS/ LMS, XMSS and XMSS^MT are "HSSLMS", "XMSS", and "XMSSMT" respectively. These identifiers are proposed for adoption into [DNSSECREGISTRY] in the IANA Consideration section Section 7 of this document. It is anticipated that corresponding numeric identifiers will be assigned by IANA when the algorithms are registered into [DNSSECREGISTRY]. Placeholder numeric identifiers are defined here- in for use in examples Section 6. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 4] Internet-Draft Stateful HBS for DNSSEC March 2022 3.2. HSS/LMS DNSKEY Resource Records The DNSKEY HSS/LMS Public Key field consists of a 60-octet 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 "Leighton-Micali Signatures (LMS)" registry of [LMSREGISTRY]. The public key of the HSS/LMS scheme consists of a concatenation of a 4-octet value L specifying the number of tree levels, followed by the elements of the public key for the top-level tree in the HSS/LMS tree hierarchy. The DNSKEY HSS/LMS Public Key field can be described as: L || LMS-PUBLIC-KEY where LMS_PUBLIC_KEY can be described as: LMS-Type || LMS-OTS-Type || I || T[1]) where the elements are defined as follows: * L: An unsigned 4-octet value specifying the number of tree levels in the HSS/LMS tree hierarchy * LMS-Type: A 4-octet 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 "Leighton-Micali Signatures (LMS)" registry of [LMSREGISTRY]. * LMS-OTS-Type: A 4-octet identifier for the one-time signature (OTS) hashing algorithm and parameters where the identifier MUST match a Numeric Identifier for an algorithm Name listed in the "LMS-OTS Signatures" registry of [LMSREGISTRY]. * I: A 16-octet 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 top-level 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 LMS-Type field and will be at least 32 octets Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 5] Internet-Draft Stateful HBS for DNSSEC March 2022 The values of the LMS-Type and LMS-OTS-Type 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. 3.3. XMSS and XMSS^MT DNSKEY Resource Records 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 [XMSSREGISTRY]. The DNSKEY XMSS Public Key field and the XMSS^MT Public Key field can both be described as: OID || T[1] || Seed where the elements are defined as follows: * OID: A 4-octet Object Identifier (OID) for the algorithm type where OID identifies a signature algorithm applicable to either the XMSS or XMSS^MT registry in [XMSSREGISTRY] 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 [XMSSREGISTRY] as identified by the algorithm number field of the DNSKEY RR. * T[1]: An n-octet root node hash from the top-level Merkle Tree where "n" is determined based on the algorithm type and MUST be at least 32. * Seed: An n-octet 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 [RFC8391]. 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. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 6] Internet-Draft Stateful HBS for DNSSEC March 2022 4. RRSIG Resource Records 4.1. HSS/LMS RRSIG Resource Records 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 [RFC8554], and MUST be generated with an algorithm consistent with 6.2. of [RFC8554]. HSS/LMS signature lengths are determined based on parsing an HSS/LMS signature and determining parameters associated with the LMS-Type and LMS-OTS-Type elements found in the signatures as illustrated in "Test Case 1 Signature" in Appendix F of [RFC8554]. The LMS-Type and LMS- OTS-Type elements of the Public Key Field of the DNSKEY RR MUST match the LMS-Type and LMS-OTS-Type for the top-level tree in the HSS/LMS tree hierarchy. Table 1 of [RFC8554] illustrates LMS-OTS signature lengths for various algorithm parameter sets. Table 3 of [RFC8554] 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. 4.2. XMSS and XMSS^MT RRSIG Resource Records 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 [RFC8391] and MUST be generated using an algorithm consistent with 4.1.9. of [RFC8391]. 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 [RFC8391]. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 7] Internet-Draft Stateful HBS for DNSSEC March 2022 XMSS and XMSS^MT signature lengths are determined based on parameters associated with the XMSS or XMSS^MT algorithm identified in [XMSSREGISTRY] 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 [RFC8391]. 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 [RFC8391]. Table 3 and Table 5 of [RFC8391] illustrate signature lengths for various algorithm parameter sets. XMSS signature verification is performed using an algorithm functionally equivalent to 4.1.10. of [RFC8391]. XMSS^MT signature verification is performed using an algorithm functionally equivalent to 4.2.5. of [RFC8391]. 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. 5. Implementation Considerations 5.1. Interoperability Across Implementations HSS/LMS, XMSS and XMSS^MT implementations for DNSSEC MUST be implemented in conformance with [RFC8554] and [RFC8391]. Implementations subject to [NISTSP800171] MUST be implemented in conformance with [NISTSP800208]. 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 IETF-defined protocols such that the same cryptographic libraries may be used across protocols. In addition to being specified here-in, HSS/LMS has been specified in [RFC8708] "Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)" and in [RFC8778] "Use of the HSS/LMS Hash-Based 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 [DNSSECREGISTRY]. Both XMSS and XMSS^MT are covered here-in 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 Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 8] Internet-Draft Stateful HBS for DNSSEC March 2022 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. 5.2. Trade-offs of Hierarchical Trees The hierarchical tree structures of HSS/LMS and XMSS^MT allow subordinate trees to be generated when needed. This provides flexibility as the entire multi-tree 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 multi-level 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. 5.3. Public Keys Public keys MUST be created with a hash algorithm providing at least a 128-bit security level. Algorithms for HSS/LMS MUST be selected from the "Leighton-Micali Signatures (LMS)" registry [LMSREGISTRY]. Algorithms for XMSS and XMSS^MT MUST be selected from either the "XMSS Signatures" or "XMSS^MT Signatures" registries found in [XMSSREGISTRY]. 5.4. Operational Considerations 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 [FUJIWARA], [FLAGDAY2020]. 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 [RFC7766]. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 9] Internet-Draft Stateful HBS for DNSSEC March 2022 The time needed for key generation and zone signing with stateful hash-based signature algorithms may vary significantly based on the parameter sets chosen for the algorithm per 6.4. of [RFC8554] and 5.4.1 of [RFC8391] with this having operational impact. Methods for addressing the above-described operational considerations are not within the scope of this document and should be addressed in additional documents. 6. Examples 6.1. Examples Scope 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. 6.2. Example Scenario The signature examples below are applicable to the following example MX record: IN MX 10 mail.example.com. 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 here-in have the following values: XMSSMT: 20 HSSLMS: 21 XMSS: 22 Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 10] Internet-Draft Stateful HBS for DNSSEC March 2022 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 [RFC4033], [RFC4034] and [RFC4035]. 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. 6.3. HSS/LMS Examples 6.3.1. HSS/LMS ZSK DNSKEY RR for ZSK in Presentation Format: example.com. IN DNSKEY 256 3 21 AAAAAgAAAAYAAAAE2OF4ZYOt5pa4NfYMpHE2P9V4aGCUzUrLNE/Z5aS1h7XgOYnx J6pVAieUcpdVUH9c OTS Private Key Used in Signature Example in base64: AAAAAAAAAABkZP///////zblWjBP79a0R/y6rG8QB1+DOhelP7+5PzHdF3+J41/8 2OF4ZYOt5pa4NfYMpHE2Pw== 6.3.2. HSS/LMS ZSK Public Key Field Elements in Hexadecimal 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. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 11] Internet-Draft Stateful HBS for DNSSEC March 2022 L: 00000002 LMS-Type: 00000006 (for the LMS_SHA256_M32_H10 entry in [LMSREGISTRY] which identifies the LMS algorithm will use: SHA256 for hashing; 32 bytes per node in the Merkle trees, and a height of 10 for the top-level tree) LMS-OTS-Type: 00000004 (for the LMOTS_SHA256_N32_W8 entry in [LMSREGISTRY] which identifies the OTS algorithm will use: SHA256 for hashes; 32 byte individual key values; a Winternitz parameter value of 8) I: d8e1786583ade696b835f60ca471363f T[1] (root node): d578686094cd4acb344fd9e5a4b587b5e03989f127aa55022794729755507f5c 6.3.3. HSS/LMS RRSIG on the example MX RR in Presentation Format 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. in.example.com. 3600 IN RRSIG MX 21 3 3600 20211203193730 20211105193730 63074 example.com. AAAAAQAAAAAAAAAEynHceojgM19r1eYeRHEHbNxS+b0IXn0+5jobp9HcR4nixqAAfloR 9OghTdO4M0Sjs8QQwqp4s/zi9kuVHzREtfuO6eynK8aQDTeCBb1yf9b/EuVwmuyB8fkE MvN0TuPtxgUg4e1wtZgafdpfTnIubnlwarEk6CqYzOFY5D3hHfI8KdbqPmRj0vBsgoqG GWlhLOLerdDDlRkpUCuaO1auPT9j5Jq+nPGIQddsR4kxfVKfKVZ8klZDQxs9+cNYKMmU anBdkAxQDzBY3uSV990lsETlEKoKb1GpLYojWucPtp6tyIZAabLhsGfXW+fsTnwJwcB+ eU17SkXd7BP5xmWVYLLIJt5Bkvfht3WVWWnHQXv6vMuznhKBdn5kPTlnUyCZLLbswZMa cu5GcbjugtBqxA2tRpeYuw9XmaJPgkyz7zCJlRFaEl4xScv9gDg98g1Z/659Lh5docKd hnndnbBheGc6QFpBB+L3WcpvK3VfIjjsijBDphwtWCJZYPc6JjldyGCiIPH78gTbbw4m vXqjTVHZEehpBPSo0wt7HN2/fuhh50MCmydidAhhlZOXLv4dUkfvIp5Hn0NAEEmBuccW NJAd7ASUKuh9pPO5yyJ7lokLe/sRAvmfuypaqe7AMCroS+nW31jOLTRhCMc/WJyTqQCo aqE8yGW47GQyBhU0JNv6wVm0ssE1INinaFpeNaGuGyQv7qJEjTWLuNiOBEpcDgb80HSx +0dUM66DTa78ODti6d2H9JvmYZK4WEhtg9vj6iQgmy6eK909WqJocx93OsRp8M4HDgAA LwpZEr+MMEY1d6SsftpOQES9bo8NncO/IgkSEP3ULvmvhTwAMmcVe9rF69WQOimCd2zK mDUPw3zsJe/coOC99URV/qGGG51j5jqQw0ng6wfFZ6mxfmdNvPmWxYAZYcLlibnavHyG iFzpU/PxqHbYa4qELWcP1aLYiSkGK54ODdF5HRGRrFP6zLdk7MHWBHf7UiMRKw3JUHUn 2fnV8Cl7t97m8hiPQIyf5RaJotjj1ePt61st5HPVg66xraA66symmrqB0NlA3wn3TlBH EYzr7ohJBlh8C6tGw4/dtTDaukSFjE6Tz0PqyQmUg1vafbOZNtmeKI3wM6hx6gHZKBYW HHSOxojZr2mA/H0/1dzkjJ6l5B4w8306RKWIon73KukOGKfB1Yak9Gkls73KgOYcZWbx MoJy9YVV2hFOcNr/dTZiu69DHcLCDFwSGP0LjDZvxe3xDoYRziOwTic2vs4WB+URDuFb Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 12] Internet-Draft Stateful HBS for DNSSEC March 2022 5kS8ABD9E4hNLRbPPHVsnaT5TpWAPwWJv3w3J5ul6Kxce5qqSHFwnpLWRfsiXK3K7Kee TVdUP2zPosJ5KqcFVhzAGo+bGc+HtMiVZ59VQAEKIbn6RJCie/PP1M4X9lB/VAfW1tnU IPWDpDT+6DTem5j71xPxLdcc49QUPhTw6l+SaVTkTJhAP1SzG20ZlxMIm8WNDGIdbTQQ LUHSExdsIw8IiAAAAAZJp9+1/ReMohNXPX7CnjWSgv0KUuL9OX80N9rLGnfN38DZ11tL EpmZWcKuYT7i9wHmEVIvaI4ZUY2K7m74LRGX/pN+0RWuklWE4dEqGLNI7gguyCvsHZ6S LpWa+iUZ9onVO/IHkgz8nybMOjK6z9z3LrmNWTq7N/FnOTD1hwsSXKe2F/NafdFLI5d9 0o+AUkSfFEHLKpIHipaJ3XYl0sALf7TEUBgz9HNj7sjhqSaSHsqWxxqDLDJc1sxgkuYt OX/ubpT/yJZpQcKJ0UBDse/HRGvpWMMIAjVky1Rou5bXaAsvvf2RZ8Z7NXEYurstbhPJ WL0NmFLdzlTRIfcm408pLN/nntC4q9t9h+8IhmRV/oY8/GXvhJ7Ar8buw99WU/Pcu0+Q ROvjraUa2Qy8nJiiJCNJJTcXrVf1Grs8u9jDRwAAAAYAAAAE5/vxPT8SR7fK19qoIwws YM0VgBX2HhNXMUj/X5UYQftzqW9rzFMUg/4Kj7w+GZ9jAAAADAAAAARcEDuVUkrpU9wt Bxp9Nxp+gVGekNtsTggRxyLG9nydkcQpjr/rtFPWYH1RD/0zDumSmx+C6+7dRSNGeVgn F4XKyADuM6O/mCJ2tN1aXoYjFp29SdpHKqzta0wvTekmdTPNTB8Lc+3JTD8V9T1ADx8k ecTiP1rrDc52cRTgPnWDSt2NhdESZ1c43nk7Bsg1DDuR9AZPMmmMTOW6aMyiDQt9Eb2t tWtiBXO3gzegmjXktbXmkSGJN8K/o0tf50CSPeX4lpYK12r0ZQ8OM/jfA5fjMpNHlQHf 14aP/qt1Sa+RD/ekRtz5JxlrCgeE7n8fpP2iW/A7EXQf8bBxDZFgdMgh6tMf8/vpxPTg ORFCl+f83bZ7Y+i8Q/FxU+lNFijjHIrVb28lXCWocivdLuI21XyOH5xwY7rMOTwNgUBz SDe0nZ9zIqpJI48SWEqDT08ID7iBJUk7S5lpNrYm3jzetlziuLrQxnmfPmL13f5xdWhJ J0QwcQB7/9IoslN9Obkzvff8PWRoGSgLBYczu0dPFOWw/MvFlVKue/cVBR/Jm7A09unA V/i7iksb++CdpcpOpB8CDpdfYR1TcWUGODhn/OOe4VRQ1ujo11cry+cM8yFciazDffZQ N54mhTner/mH0ko/ED95Do3Gz897DmpMFmdxypP9UVSNuMS1m7RxlPUJF5gHU2swzi4U DMyQl+8q5r1PNx1mBXo+ylVnRLa4aRWb3us1PJUe3VZjQH4b03XF2EOcok1RVBrHZIQi 7wHk3QOS2CL2C0yXXkr/uvQ0qqREXiXzQY2vBUiXFa0qS2Z8JEh6iVyQno1r09CDOdTZ eVhJor5pGAT74pDzhJSJ9lDhBbqI5wBUk/Y7s+NbF8X0UgSpBToyUvDo+i/BuulFrgM+ nfmSYSqItLVfpWtRwzoQxaHYAbC/OEdOsUS8xxIUi2LB/Gs7hUKsLoG2YqRp+jqSISm5 +VeocjvU6rbQPUB/BC0a2L5Xyvd3zdcDe09ZSD6svHEpqetp4AHdUiqBqxBVKVDfvInp FXkeZ3s3F2fPgwAkAidadDH9OpDeCDEJyMUhAmi1n3hGaUqF5Pob4RuGJ235wGpQSJnp N/VilDYDualtN6O1bm2QswMlugfU/4V4fqkc2+htkU8ZiNVDUthirfgBf2+rnqtzFMS5 /ciCHpUE2hVvQ7LV2zUDXo/K+6iQRHg+nycaQ9B6UnpeFQ8QS5u7T8VrasooTrZPSLTP LafiTaJWdKFwmLFDXYQSas9gmDMRej1OkLwMGWtL+UbsjrLCmds9W23TBqcteyaKx1va O1eNTCEsqipOaC553SnUiwp77ImW9MxIxVPQGb6h31X7P/8Kq5Xg/ayFKRvXkI+I4ZmL 6Qk/SzkI3CvdssgyQAouFSCRS64Jlf5cZXVXdxy6HP4TLfWvEPoO3S3jElqvDBC6yPYW DxHEAbP1NzPl7+Zqohzvi4JpH0qsndSHuHfndr7eoIwnY5BzkTrfAAAABnKlwPzZ1s6r S4Xq/PWp6+55bQ3SRAwbYlG5J4hXCZiYsYSznaor6R6PDYPYqoRFaFwFkS8f1QIqYUql Vk50xqjuVod+6DafgrSosIDseLjKllw3kXcUCLVT1M0QbeGxzWGGwLR4UeImrDn4uShA Ng5SvotYccWZbgak0GV8FUvzP37THwNqy3Ag52Bac3BqSvjjzZ2lpJRy/5yT4ap5b+Qs 0TCMwsHZCY7M/8iVtENd/gq2/Tn5JggvBjwH775qtTfujTWZjUS9JZsHqjITWuxG8VsV 3KUHbovGyr18RjSzgJ6UtStWhlTB8idCaooGGA0RjXNK41+N9gpU3wAOcVpXvy8zhcwF cMWvoPvm3ldN/EwSheFs4+t5sFQWZXeybfsVYLC/uNL8qRoNLOBBeuzTCtJuMw9bPAPJ biUrajoc 6.3.4. HSS/LMS RRSIG on the example MX RR with Elements of Signature Broken Out in Hexadecimal 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. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 13] Internet-Draft Stateful HBS for DNSSEC March 2022 Nspk (number of signed public keys in the key hierarchy = number of tree levels minus one, as the top-level tree's public key is not signed): 00000001 Index (index of the OTS key from the bottom level tree that was used in creating the bottom level OTS signature): 00000000 LMS-OTS-Type: 00000004 (LMOTS_SHA256_N32_W8 - uses SHA256 for hashes with 32-bit hash values for key elements and generated using a Winternitz parameter of 8) Random Seed (the random seed is used in signature generation to make it harder to perform attacks on the signatures): ca71dc7a88e0335f6bd5e61e4471076cdc52f9bd085e7d3ee63a1ba7d1dc4789 OTS Signature (1 row for each OTS signature element plus the checksum): e2c6a0007e5a11f4e8214dd3b83344a3b3c410c2aa78b3fce2f64b951f3444b5 fb8ee9eca72bc6900d378205bd727fd6ff12e5709aec81f1f90432f3744ee3ed c60520e1ed70b5981a7dda5f4e722e6e79706ab124e82a98cce158e43de11df2 3c29d6ea3e6463d2f06c828a861969612ce2deadd0c3951929502b9a3b56ae3d 3f63e49abe9cf18841d76c4789317d529f29567c925643431b3df9c35828c994 6a705d900c500f3058dee495f7dd25b044e510aa0a6f51a92d8a235ae70fb69e adc8864069b2e1b067d75be7ec4e7c09c1c07e794d7b4a45ddec13f9c6659560 b2c826de4192f7e1b775955969c7417bfabccbb39e1281767e643d3967532099 2cb6ecc1931a72ee4671b8ee82d06ac40dad469798bb0f5799a24f824cb3ef30 8995115a125e3149cbfd80383df20d59ffae7d2e1e5da1c29d8679dd9db06178 673a405a4107e2f759ca6f2b755f2238ec8a3043a61c2d58225960f73a26395d c860a220f1fbf204db6f0e26bd7aa34d51d911e86904f4a8d30b7b1cddbf7ee8 61e743029b27627408619593972efe1d5247ef229e479f4340104981b9c71634 901dec04942ae87da4f3b9cb227b96890b7bfb1102f99fbb2a5aa9eec0302ae8 4be9d6df58ce2d346108c73f589c93a900a86aa13cc865b8ec643206153424db fac159b4b2c13520d8a7685a5e35a1ae1b242feea2448d358bb8d88e044a5c0e 06fcd074b1fb475433ae834daefc383b62e9dd87f49be66192b858486d83dbe3 ea24209b2e9e2bdd3d5aa268731f773ac469f0ce070e00002f0a5912bf8c3046 3577a4ac7eda4e4044bd6e8f0d9dc3bf22091210fdd42ef9af853c003267157b dac5ebd5903a2982776cca98350fc37cec25efdca0e0bdf54455fea1861b9d63 e63a90c349e0eb07c567a9b17e674dbcf996c5801961c2e589b9dabc7c86885c e953f3f1a876d86b8a842d670fd5a2d88929062b9e0e0dd1791d1191ac53facc b764ecc1d60477fb5223112b0dc9507527d9f9d5f0297bb7dee6f2188f408c9f e51689a2d8e3d5e3edeb5b2de473d583aeb1ada03aeacca69aba81d0d940df09 f74e5047118cebee884906587c0bab46c38fddb530daba44858c4e93cf43eac9 0994835bda7db39936d99e288df033a871ea01d92816161c748ec688d9af6980 fc7d3fd5dce48c9ea5e41e30f37d3a44a588a27ef72ae90e18a7c1d586a4f469 25b3bdca80e61c6566f1328272f58555da114e70daff753662bbaf431dc2c20c 5c1218fd0b8c366fc5edf10e8611ce23b04e2736bece1607e5110ee15be644bc 0010fd13884d2d16cf3c756c9da4f94e95803f0589bf7c37279ba5e8ac5c7b9a aa4871709e92d645fb225cadcaeca79e4d57543f6ccfa2c2792aa705561cc01a Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 14] Internet-Draft Stateful HBS for DNSSEC March 2022 8f9b19cf87b4c895679f5540010a21b9fa4490a27bf3cfd4ce17f6507f5407d6 d6d9d420f583a434fee834de9b98fbd713f12dd71ce3d4143e14f0ea5f926954 e44c98403f54b31b6d199713089bc58d0c621d6d34102d41d213176c230f0888 LMS-Type: 00000006 (LMS_SHA256_M32_H10 - Indicates the LMS Tree uses 256-bit/32-byte hashes and has 10 levels in the tree) Authentication Path (1 row for each node - contains a sequence of hashes within a path through the Merkle tree for the signature and which is to be walked during signature verification): 49a7dfb5fd178ca213573d7ec29e359282fd0a52e2fd397f3437dacb1a77cddf c0d9d75b4b12999959c2ae613ee2f701e611522f688e19518d8aee6ef82d1197 fe937ed115ae925584e1d12a18b348ee082ec82bec1d9e922e959afa2519f689 d53bf207920cfc9f26cc3a32bacfdcf72eb98d593abb37f1673930f5870b125c a7b617f35a7dd14b23977dd28f8052449f1441cb2a92078a9689dd7625d2c00b 7fb4c4501833f47363eec8e1a926921eca96c71a832c325cd6cc6092e62d397f ee6e94ffc8966941c289d14043b1efc7446be958c308023564cb5468bb96d768 0b2fbdfd9167c67b357118babb2d6e13c958bd0d9852ddce54d121f726e34f29 2cdfe79ed0b8abdb7d87ef08866455fe863cfc65ef849ec0afc6eec3df5653f3 dcbb4f9044ebe3ada51ad90cbc9c98a2242349253717ad57f51abb3cbbd8c347 LMS-Type: 00000006 (LMS_SHA256_M32_H10) LMS-OTS-Type: 00000004 (LMOTS_SHA256_N32_W8) Public Key Identifier: e7fbf13d3f1247b7cad7daa8230c2c60 Root Hash of lower-level tree (public key for the lower-level tree which is signed with the OTS signature below): cd158015f61e13573148ff5f951841fb73a96f6bcc531483fe0a8fbc3e199f63 Index: 0000000c LMS-OTS-Type: 00000004 (LMOTS_SHA256_N32_W8 - LMS_OTS Type MUST be the same for all instances within a signature) Random Seed: 5c103b95524ae953dc2d071a7d371a7e81519e90db6c4e0811c722c6f67c9d91 OTS Signature (1 row for each OTS signature element plus the checksum) c4298ebfebb453d6607d510ffd330ee9929b1f82ebeedd4523467958271785ca c800ee33a3bf982276b4dd5a5e8623169dbd49da472aaced6b4c2f4de9267533 cd4c1f0b73edc94c3f15f53d400f1f2479c4e23f5aeb0dce767114e03e75834a dd8d85d112675738de793b06c8350c3b91f4064f32698c4ce5ba68cca20d0b7d 11bdadb56b620573b78337a09a35e4b5b5e691218937c2bfa34b5fe740923de5 f896960ad76af4650f0e33f8df0397e33293479501dfd7868ffeab7549af910f Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 15] Internet-Draft Stateful HBS for DNSSEC March 2022 f7a446dcf927196b0a0784ee7f1fa4fda25bf03b11741ff1b0710d916074c821 ead31ff3fbe9c4f4e039114297e7fcddb67b63e8bc43f17153e94d1628e31c8a d56f6f255c25a8722bdd2ee236d57c8e1f9c7063bacc393c0d8140734837b49d 9f7322aa49238f12584a834f4f080fb88125493b4b996936b626de3cdeb65ce2 b8bad0c6799f3e62f5ddfe7175684927443071007bffd228b2537d39b933bdf7 fc3d646819280b058733bb474f14e5b0fccbc59552ae7bf715051fc99bb034f6 e9c057f8bb8a4b1bfbe09da5ca4ea41f020e975f611d53716506383867fce39e e15450d6e8e8d7572bcbe70cf3215c89acc37df650379e268539deaff987d24a 3f103f790e8dc6cfcf7b0e6a4c166771ca93fd51548db8c4b59bb47194f50917 9807536b30ce2e140ccc9097ef2ae6bd4f371d66057a3eca556744b6b869159b deeb353c951edd5663407e1bd375c5d8439ca24d51541ac7648422ef01e4dd03 92d822f60b4c975e4affbaf434aaa4445e25f3418daf05489715ad2a4b667c24 487a895c909e8d6bd3d08339d4d9795849a2be691804fbe290f3849489f650e1 05ba88e7005493f63bb3e35b17c5f45204a9053a3252f0e8fa2fc1bae945ae03 3e9df992612a88b4b55fa56b51c33a10c5a1d801b0bf38474eb144bcc712148b 62c1fc6b3b8542ac2e81b662a469fa3a922129b9f957a8723bd4eab6d03d407f 042d1ad8be57caf777cdd7037b4f59483eacbc7129a9eb69e001dd522a81ab10 552950dfbc89e915791e677b371767cf83002402275a7431fd3a90de083109c8 c5210268b59f7846694a85e4fa1be11b86276df9c06a504899e937f562943603 b9a96d37a3b56e6d90b30325ba07d4ff85787ea91cdbe86d914f1988d54352d8 62adf8017f6fab9eab7314c4b9fdc8821e9504da156f43b2d5db35035e8fcafb a89044783e9f271a43d07a527a5e150f104b9bbb4fc56b6aca284eb64f48b4cf 2da7e24da25674a17098b1435d84126acf609833117a3d4e90bc0c196b4bf946 ec8eb2c299db3d5b6dd306a72d7b268ac75bda3b578d4c212caa2a4e682e79dd 29d48b0a7bec8996f4cc48c553d019bea1df55fb3fff0aab95e0fdac85291bd7 908f88e1998be9093f4b3908dc2bddb2c832400a2e1520914bae0995fe5c6575 57771cba1cfe132df5af10fa0edd2de3125aaf0c10bac8f6160f11c401b3f537 33e5efe66aa21cef8b82691f4aac9dd487b877e776bedea08c27639073913adf LMS-Type: 00000006 (LMS_SHA256_M32_H10) Authentication Path (1 row for each node): 72a5c0fcd9d6ceab4b85eafcf5a9ebee796d0dd2440c1b6251b9278857099898 b184b39daa2be91e8f0d83d8aa8445685c05912f1fd5022a614aa5564e74c6a8 ee56877ee8369f82b4a8b080ec78b8ca965c3791771408b553d4cd106de1b1cd 6186c0b47851e226ac39f8b92840360e52be8b5871c5996e06a4d0657c154bf3 3f7ed31f036acb7020e7605a73706a4af8e3cd9da5a49472ff9c93e1aa796fe4 2cd1308cc2c1d9098eccffc895b4435dfe0ab6fd39f926082f063c07efbe6ab5 37ee8d35998d44bd259b07aa32135aec46f15b15dca5076e8bc6cabd7c4634b3 809e94b52b568654c1f227426a8a06180d118d734ae35f8df60a54df000e715a 57bf2f3385cc0570c5afa0fbe6de574dfc4c1285e16ce3eb79b054166577b26d fb1560b0bfb8d2fca91a0d2ce0417aecd30ad26e330f5b3c03c96e252b6a3a1c 6.4. XMSS^MT Examples Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 16] Internet-Draft Stateful HBS for DNSSEC March 2022 6.4.1. XMSS^MT ZSK OTS Private Key used for the example signature below in base64: AAAAAQAAIJbk253wVxcPn3z6ztrGaoLgosugukEzj4EQPv1fRSrbBiM1C3cvkrS/g0uE Oqx4eaOxnUWNK9AxS8Pavutf6mX4gI5f9LRt7OMvtZG9fqzYJ0I/6Oxbhwr5nwh7Mig2 mTzwEuZvQ+UZI9Jd8xYP4vbBzegvkIK5esy3pNjVBR8p DNSKEY RR in Presentation Format: example.com. IN DNSKEY 256 3 20 AAAAAfiAjl/0tG3s4y+1kb1+rNgnQj/o7FuHCvmfCHsyKDaZPPAS5m9D5Rkj0l3zFg/i 9sHN6C+Qgrl6zLek2NUFHyk= 6.4.2. XMSS^MT ZSK Public Key Field Elements in Hexadecimal 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. OID: 00000001 (for the XMSSMT-SHA2_20/2_256 in [XMSSREGISTRY] which identifies the algorithm will use: SHA256 for hashing, use aggregate height of 20 with two levels of trees, each of height 10. Note that XMSS and XMSS^MT both assume a Winternitz parameter of 16 for OTS signatures) T[1] (root node): f8808e5ff4b46dece32fb591bd7eacd827423fe8ec5b870af99f087b32283699 Seed: 3cf012e66f43e51923d25df3160fe2f6c1cde82f9082b97accb7a4d8d5051f29 6.4.3. XMSS^MT RRSIG on the example MX record in Presentation Format 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. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 17] Internet-Draft Stateful HBS for DNSSEC March 2022 in.example.com. 3600 IN RRSIG MX 20 3 3600 20211203193726 20211105193726 44758 example.com. AABLykUnzyJ2aWKh8e9smKgzAIlASWsKaPYjn9+sNU6y2e6oQUKgfvtljYtN/K8KBsgu /crA+ONXlmiw3unYS47sN+J4/xIIWHOG+Ojn+ZWeGQdPQ7M5i+cM9yytSymTm0z1c1Oq EC1GdYJQqnHQ1v/AErOVUFhDKIfh2UFh9bJuQD+zacpMYyIGUakfHBF/9wcw5OHWD9Hd qDtyiGygYQEzxgj5ZY6tC+nfLQHcCgjqMx9xudTuvc1oyoDLWlCTiwqBzUuUh+5z5jqH GafAGoV/Ymp1s3xbCGmwlSCHEdTeZD8BB9ZZtVVi20ame3cpvUC37NSegVrwLq/Gtdnk MdRNUW4eSDEjoDQX+4Z3AtZ86bkG/asidXM581YovrjHTVxNeoLd5dzEW47Eqs/YK2Uf O8D8gmlWiCO94zHOgoKoFkRTmThaNioKlcoLbWpjCWMqfmbhGko0Run0lb6u36Dn5rJ3 O6zAA6r3PxAMlZrB8cwAn5h8Md/DLvcePwqVMB/33OVatPsZbd9SDgnBTeKW7Gd7LQkb WKS/XnvEIMgrrm9Isp0xUzJVdb/F5wwEWEZQVKdDuR6Jshtotbs2lBY8vwHXlOlK0cNS jdjfiRhuQYNR60MvVRRtHsZWHw/N+FfbtVV4dIyP1RqwtfaX8vlVZ3eHsREdoPlx877p DEsWQdd0Xj88uph1UJKynmVsOrjPMArFzweoeG0jDHbmroSevUKfGOlDIoG8L1xEAk2t qkHRv63+2xhBnWd6fw/OuH85WQSi5tGZ2EnaCXdAh8UhPOg2J0rbwXFI0f/QITDIkGtl CtqcGU6U3aXBCGekufwvPSWCY9KyVptNBFS5aWj0bUWLZaUuYapU1S/JWlUj1x8TwCaU PNfVS4lBqbUNP8fsM5P9pfnKl7ZKD3q9RrKO1b+Zo8I9zIL7s4LqfKcD6WJJeYFI79QD f7upKRmmtjvahQp56BqFFON8pWxuhJH8FAnKDS/e9/0DXTtD1sMgtT0mnbGBsYz+57hr tvLV2wp6sh+AgdGKIHlvhaETHKE3DzqJKR2ZH/YNM/WIm/l+coplZgTLh2ZbW6tlYMfR JxXYoHMJFjHT1uHB7g1XSWiHoFCosTIcweTfSq058LFJOvTcuQzXNXWY1FXHjF65jcPZ s1G3Fgi5MX+LqXBDxZuFC/WMOJDrNbuuW9xZcB94uMB5IHNHpKS8d9svMQ+YucEF9t4b B9nUS817AB7hwS/Ke1L4UhbX8QEU7P29uvAL+6/Us/f0A31et0G7MEyhpf5FDKPXnAR0 s0FtWMy+e6TM5GQ8BsIHnYwEvPpazmwaZJwHQi5waZgOn31j1BWJiJT0AD2k+e2lJ40g nU6vbCqJC1NcBa99kciVBmot22VvJ0qfNpYGs6GhF9bEMm6/g3JXe59WC1WZCp/hhcSZ V8s/Wrttoz4e3CIWof3C+C02oveofhHAc6ElSC4bRCfBniOz6WSL3UE/rAYvfl1h8x3B 8YyQ6PRVsyTAQQz8jXUDbNTNBe9/vgz5ZSH2IcSda/1TY2a4FKSiCMI9JK0Du5qn5yJu M8321VBdxS4Swz/mh0RJQW3/Joqr4HWHG++zcxc4d9KM+JIyrx5Ik1eSOxMmJGg24YdA k2UZ8+mgbOD5L4cyBgx3SMWzrlDK9+LjNiCYSXuJfQ104Rt325efDIpokY11xmJc2c+i eU+ZUB+CCRpht6pXw/nLSnk8Hda2LXz3zX5KEhW5Alm1gIN/XpMGKl1uEBo4KhwaHYi9 TlsSsjRrMJgRxMPAfEcB64w9R3nsZGjHqKj1H01vhDWdNX6x+wbP24Pr/4t0mb1WdlK7 fzA4FPLkWzWhgEsGZyYAgVw15EaweCMf5Dk7wA1QKD6iAApZ/r0Ep1yOyLWhsfCKJxcH DEMDIR/Rj62bUCutA5V02reA5HWUikCeSlCDNxMb02G9B2T/FFdWJMQrokmEnemaHy0G tMemdYPj6rNgkS4fnqd9rR3Q2sqP2AUQ3C3REj43ezt+A9dMiwXVcez8BDmbEG5Mnn1E moYEstVtJjdAuzkVdRzvDDlF2Z7DLSLTQXTpI5txgcUnhTuE3Et11cNThQYie4tOoNOT WtHvL8BwU1hbTxT2RyPHB/VGquuxg1VSZvGJeOiYYyava9nVfpF2MrjsTvFONQA9hkuU OhjBUILWu9830l+dTUUw47wlNAopPwtdkXyxRDtfDzx3WKHov55hWL3OZCy3xGQa1y2H 1c9MipK4XFqOBYsq4r2LZgk5cwrjeaaiyVvjDGQe9ceQFXAZ42w3FRDGfxtuQf7hh0qi PQhOUaPbGtn1WgBuVAY1ifBg9zlEteUV8ndeLuvM/UHSIUiQLcGCNeg/su6zqLtzrjGM otBOpv3YR6lUWq8AKumZXnLBNxJPsC4CpQEYyn3PYpYMXYc1HPGV/3bwbS3rWV+Nd96t IXZ8ULv8CVoKGOdC/gmm2X53Ub/DQC+qcLLlJNTv18TaFZW0bhP/h7otmHwdeesFF51q 6Kr4zdR6orU9qSOblBQ/EAjhgi2LN3ZFuDwgIL4+tPUj2HwZEpnF0KC/hYewE1m6usPA Ap/LMR72kcnkJ9ozOkFR1Et8Pbn2bgkq/91QY5fK2mt5urFPhjRmMCT19/IfJbN2JGgF NSOmbyWEDhqCg/wvSPHOhWERq0Y1wh0SE5UaJsOpuKQfioUq6H7LMrBBWH7q/RFtWljq Nvxwsz3LYvywyWokWFl+Cd07BhQROJQP8GeRzTxHLzORFfVBG70zYrcY+JMtwG4oyT6R yUFzQtJNM+T0JkrkTpLK2JRDFKG5bC2vK7fvRsRpiQtmtvq4K/Umyw94HhGaQiq6c4kw 2pV+IpJZuwPD9FytpyRtOUl5bGBzMjf7rsXqLpV/dEbp2TYGWgjkaZFFMQPxjj+tcVoe 6XIkQDmfNfHAvm5Du/uYT+ZwbyukXkB40Gs4WBLMfKi3PqQeFWYbxBgtkdD7TsQKsP9+ bxfO/fsJNgvxg80y0LnTL+Fuogtrsavlx6z7tYnnxvOdVCtcdNCnt3xwQZgWMydJzP// jIVBWdeSlBO0/Wc8924bZgH2A/BO3CP/Hc7HJcVQD2sIP5CMwnPoLuu8f+ahi7Te5l4K Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 18] Internet-Draft Stateful HBS for DNSSEC March 2022 thKGGfXEEcRYOeQ9+XcJ5MHlqIpcySMjlk5wn0dYylepQMh5AKYFc5D6ynOgJgMGkW+e xCMF51ZRLXB3puaFutfV7gKWpqESvhNXE2fT/RHmxDms5Ag2yNwxQDZTTxjiZhXxE5aI p3di5p09QGtPPfv1YjSlQeZ2RlTqXQhBdbW7CLz/8WCXWdpNCkI7Re1X6F6gP6ysRgwO 5s0EGWqTlgHDLXFtEYd3OHYiMqI/s2R/D8QgtKcpz+wCPINVDqdXjXLXzyIy7IlM31vE A6tXu8SeNXFcysj3RNta3AvrVGwTLVtlRIIn7g6S+s3t9XGSLHqw5TfNQnJyfMdtn+1B iI9Xu713J2E0HVBHawAeaewuGSGVBizUc8xqJXh8DkWgTRdijtBqKfbvY5ctqjZtW3IZ HwSJuynbFHVmi8/czsaymj5cBV7g4aLzACc6XgMaU6A1fZ9EJ8onlFanXEJQxCh/ik3b c1IQvVug7FVPjTiv3yp19yGBedU0SlHVciOeam0wPA3fG73Rov6bzHp80ihYgYNgs7ME MUFiqzHL15IbEVFEcg6IzakISVleRememnJPAzcae8Z/HILXUmx/IokIvMOeQcYt3HTa XQLX7TzY2o2AIX/1QHpLCKZqtzcU91eapVkF1u5mWD3brwGdMlk3Qa4DphqeOe+4QAb3 mwjuILalyBeKEC4iqcw5Y05FKzNeU7WU7ms8VCzcmrTh8gpzZcY7f4HXoWGLpYsm5ist ehmFlKi0c1oeZi5zBKRfP6bP9cgZo4KkdLUow+BKSOhrK5lWcOAyLJrXet7g5CiKaWyt TUV5fxnuNiJvCjottu6QTS1ySAJR02uwpubY1BwLs1D9bRBeCZiCS02nwuRHIox1PaOv 6KO4sdcW+/Cp5BTElyQfvV1ubgvywQzCBVHA1xktue3kGFBiB6ujez2xfVrU10e6VgKH DmPjCyxQ/jvlJ7VjjwOOM9nVvwS0qDoDqQ0dfkZFlsJdA7YvW1mlV4XyKwOH5FDkRfZt MKMAg5usdPE/bu5b21R8aU9dNaqahTmP3hj48vZ41gssvGOKsG8sPTgPK7lxVRTvQrg8 8CpIi1L04kfHlXdvwmiA92JKKW72BrKRqK06VktyQ1FEm3fl72LIKC0wZX4d95lWCbN0 w57CsuEQ50uDylToCB1BbTDlPoEEWF+ZuaZS/rB3DN4bQKFYBDgsuaJElJpbWTbiS1Wv 2NwsvPlhwLTXAQa2QP61ADnIuxMV6N9MgZs7rkHWPJhh52AFm3jRfuXOOB7xKCk+DPxE SamOPeb+u1WPwDaMHJWy8iixpQvBhf4hkgzE/twZJ0Tsl0KXRPkypV7m1ClK1qei6p0X GIb/5WcKZjghdmVyqXKIu36+QSfnM3FDdSmEt2tRf62cuIfQ7UzlPc2gDbrjL9vSec0y KQSQnKgDgCxTxj01CtMyMRY8yZuLn/Typk0Nm3HafZhR7HAnsy/d0oENkOwKXqq1RiZx OOemEKsngP8j6vcUkUE5BnZA8Aspmmciej+Pabwluuz+Gzs3nPNFvOOM4uRbirXuBw7T W/tBtAoFXxpwEjxMsCvxDOE/RQpy6OufLqB/KtPuSXvwe7Y/W6JjvvflGnbs38le+Yps NjkFEgXxipTi30qxOz//GWKw8WjaMyK94Em4UQXg2I7Hp/tDV9F7IWlOYvbCHQEotTNP DmxNdueRXI83YgDYzqYW6dEJQSTBjYiBM97esSIjSvf7gkR1lT4xZOMoRogat9eTzKcv c/kZ+8Q/qVGf0D60E64Nm/dxRNXzsOjACznpEx6iaCIm3nIu/mMpAciSr+8eLgb7RYB+ XUeMonM2Ozd4D7H3b7pTipv6Xoe9CUZ2NDK+s0yjfIcMmWI9TsEG+B0fpMJYyVP9FfAk 4xGjmw5damlzdZ1iFB/mTj0DQeLsWYBUM/vjcfGJ66M1SswfzopG9yiIJULkigMYSgJ2 D4EkInVKGB2hqO4YLNSgx4qNJEX/lGXdLWrYdSmjyPT41591+JoB9/SV1zX5xMli5Rvy 6cUN0nCWT0VRJoyP23vl2y/p7Gt3kXuxiBcGT+eSbHg5XYPkQguhcKdI7aYZGPo8dvJd pbRYopgcqDp6Uuw8NWvEBZrAoWskZj7gL954XFNpvu968MeYUAU6LWoSwe1Q67VleC3D YV8+1x/NEzy/pR6cCUImoEx++D4wRZt2mbHgrjfh6V7JDLmp02CMeb0URdfZNAY1q4VQ 1Cgo3W4ASky2drEcv/yh63GgDWR+Z0YmONcnAH0GcaSC/b5o4PlC/fo0OQldYjRho/CU nlfPc5FbPUgdlwYeuo3YYMPeRjeAO9vwzlETb3eyvU7WOB8TVvfJzEIWAXV0823xDV0k 4g/zZxg87tgdjNvGl2isZqoK8UCCNOq7tuHcQCDMkMa0WD5um9MetAOuIN+z03yy+MEu IgrWOWNIrBHo881YdrssxEjv7HSMz+PLF28nSsIPdlHgRZABr/Vz6XE6/S9mum4NrNnV hbIO1Q9vCXF35jiE/srqg6P5N1SwQWM1O95i9cDynYa6c/VXF02JTnD+bkM/0pjclS7y kg631wGHeg08BkxMomDoCci7/lrYdVJQdz0ehESFrEuDqn+/0YmWGvymWPD6scrttpil 5e4spXJRumMUGwgAnKXWWIeRcoKehPOvwQUdVFmxoiLBEanNcvvfPX2yFgiB8EfdCP6h NFWJnJWOJQ6bN2spJFdCImoZpgmGQboH8O4gVPn0Gp5wEgjQCVJTNf9UTM22zrqo2DFD kXerHy+BZlBI5w4gQnVKX5LJV8v+QRDgHRvdPZHrBuc/9PHiMC9/WEo8+Sxw4HgiHdML vGzRYWDyLfZZJWUB2aQlmXJnAoir642qSe1Gqe42DEStZfgScIs9cgOJqZSXWyNRjBJU jPOunhttIQQFDq2J8DXaXBPpoxG1KWh7elvJHwUUdk7Xer/VtF+A/N8KskzMxlI99fi7 jaCgsy4TXO4F8NcHAD7CWBLTtU1mNUF7vL5Dr7bTEXNiDtOkazfYM53ovzZsg79viGUF xZZcIRDo8Uso3B0DhV6Rs0gQVM4CSRSr7cYeVHbCabVDRXZ/vrEcTZMQcQTdLh023D7l ylLESSjN43I8JkOkc74fSlBWZ2zQVFRQ48ZtRFlGNF5bu622fYTNothUQ1eAJWCqIFyu AMncNmF6k2aGsQaiqA1WGzsjfDAollBjRsWf5acfLX3eCFwBq5GQIyL+4xjrugD7tQyl Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 19] Internet-Draft Stateful HBS for DNSSEC March 2022 uI8LW/Kxj1GyiqyAs40Gdbvt7UrB5FNZaZcX6tmmVDdIdDpNLvYwm+PiGMMXmXGI8pFS zOKPTN7tfvcZ4yB5G1Z29BVCpm1NvVOvTtqM0oZtTFWOzi8sDNLGUZEz6LAyXRU/+tq8 x0R0SBCP8s+E80P7sWXNfr47Qk6hZfFNX/KioWRN2+hxjx+K523bGwUitDxa0IV2dDGm 9P5HKhipqyC/D0MGAXJebAAPFAMAAA4QYapx9mGFh/au1gdleGFtcGxlA2NvbQACaW4H ZXhhbXBsZQNjb20AAA8AAQAADhAAFAAKBG1haWwHZXhhbXBsZQNjb20A 6.4.4. XMSS^MT RRSIG on the example MX Record with Elements of Signature Broken Out in Hexadecimal 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. Index: 00004b (index of the OTS key from the bottom level tree that was used in creating the bottom level OTS signature) Random: ca4527cf22766962a1f1ef6c98a833008940496b0a68f6239fdfac354eb2d9ee (the random seed is used in signature generation to make it harder to perform attacks on the signatures) Reduced signature for bottom layer tree: OTS signature: a84142a07efb658d8b4dfcaf0a06c82efdcac0f8e3579668b0dee9d84b8eec37 e278ff1208587386f8e8e7f9959e19074f43b3398be70cf72cad4b29939b4cf5 7353aa102d46758250aa71d0d6ffc012b3955058432887e1d94161f5b26e403f b369ca4c63220651a91f1c117ff70730e4e1d60fd1dda83b72886ca0610133c6 08f9658ead0be9df2d01dc0a08ea331f71b9d4eebdcd68ca80cb5a50938b0a81 cd4b9487ee73e63a8719a7c01a857f626a75b37c5b0869b095208711d4de643f 0107d659b55562db46a67b7729bd40b7ecd49e815af02eafc6b5d9e431d44d51 6e1e483123a03417fb867702d67ce9b906fdab22757339f35628beb8c74d5c4d 7a82dde5dcc45b8ec4aacfd82b651f3bc0fc8269568823bde331ce8282a81644 5399385a362a0a95ca0b6d6a6309632a7e66e11a4a3446e9f495beaedfa0e7e6 b2773bacc003aaf73f100c959ac1f1cc009f987c31dfc32ef71e3f0a95301ff7 dce55ab4fb196ddf520e09c14de296ec677b2d091b58a4bf5e7bc420c82bae6f 48b29d3153325575bfc5e70c0458465054a743b91e89b21b68b5bb3694163cbf 01d794e94ad1c3528dd8df89186e418351eb432f55146d1ec6561f0fcdf857db b55578748c8fd51ab0b5f697f2f955677787b1111da0f971f3bee90c4b1641d7 745e3f3cba98755092b29e656c3ab8cf300ac5cf07a8786d230c76e6ae849ebd 429f18e9432281bc2f5c44024dadaa41d1bfadfedb18419d677a7f0fceb87f39 5904a2e6d199d849da09774087c5213ce836274adbc17148d1ffd02130c8906b 650ada9c194e94dda5c10867a4b9fc2f3d258263d2b2569b4d0454b96968f46d 458b65a52e61aa54d52fc95a5523d71f13c026943cd7d54b8941a9b50d3fc7ec 3393fda5f9ca97b64a0f7abd46b28ed5bf99a3c23dcc82fbb382ea7ca703e962 49798148efd4037fbba92919a6b63bda850a79e81a8514e37ca56c6e8491fc14 09ca0d2fdef7fd035d3b43d6c320b53d269db181b18cfee7b86bb6f2d5db0a7a Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 20] Internet-Draft Stateful HBS for DNSSEC March 2022 b21f8081d18a20796f85a1131ca1370f3a89291d991ff60d33f5889bf97e728a 656604cb87665b5bab6560c7d12715d8a073091631d3d6e1c1ee0d57496887a0 50a8b1321cc1e4df4aad39f0b1493af4dcb90cd7357598d455c78c5eb98dc3d9 b351b71608b9317f8ba97043c59b850bf58c3890eb35bbae5bdc59701f78b8c0 79207347a4a4bc77db2f310f98b9c105f6de1b07d9d44bcd7b001ee1c12fca7b 52f85216d7f10114ecfdbdbaf00bfbafd4b3f7f4037d5eb741bb304ca1a5fe45 0ca3d79c0474b3416d58ccbe7ba4cce4643c06c2079d8c04bcfa5ace6c1a649c 07422e7069980e9f7d63d415898894f4003da4f9eda5278d209d4eaf6c2a890b 535c05af7d91c895066a2ddb656f274a9f369606b3a1a117d6c4326ebf837257 7b9f560b55990a9fe185c49957cb3f5abb6da33e1edc2216a1fdc2f82d36a2f7 a87e11c073a125482e1b4427c19e23b3e9648bdd413fac062f7e5d61f31dc1f1 8c90e8f455b324c0410cfc8d75036cd4cd05ef7fbe0cf96521f621c49d6bfd53 6366b814a4a208c23d24ad03bb9aa7e7226e33cdf6d5505dc52e12c33fe68744 49416dff268aabe075871befb373173877d28cf89232af1e489357923b132624 6836e18740936519f3e9a06ce0f92f8732060c7748c5b3ae50caf7e2e3362098 497b897d0d74e11b77db979f0c8a68918d75c6625cd9cfa2794f99501f82091a 61b7aa57c3f9cb4a793c1dd6b62d7cf7cd7e4a1215b90259b580837f5e93062a 5d6e101a382a1c1a1d88bd4e5b12b2346b309811c4c3c07c4701eb8c3d4779ec 6468c7a8a8f51f4d6f84359d357eb1fb06cfdb83ebff8b7499bd567652bb7f30 3814f2e45b35a1804b06672600815c35e446b078231fe4393bc00d50283ea200 0a59febd04a75c8ec8b5a1b1f08a2717070c4303211fd18fad9b502bad039574 dab780e475948a409e4a508337131bd361bd0764ff14575624c42ba249849de9 9a1f2d06b4c7a67583e3eab360912e1f9ea77dad1dd0daca8fd80510dc2dd112 3e377b3b7e03d74c8b05d571ecfc04399b106e4c9e7d449a8604b2d56d263740 bb3915751cef0c3945d99ec32d22d34174e9239b7181c527853b84dc4b75d5c3 538506227b8b4ea0d3935ad1ef2fc07053585b4f14f64723c707f546aaebb183 555266f18978e8986326af6bd9d57e917632b8ec4ef14e35003d864b943a18c1 5082d6bbdf37d25f9d4d4530e3bc25340a293f0b5d917cb1443b5f0f3c7758a1 e8bf9e6158bdce642cb7c4641ad72d87d5cf4c8a92b85c5a8e058b2ae2bd8b66 0939730ae379a6a2c95be30c641ef5c790157019e36c371510c67f1b6e41fee1 874aa23d084e51a3db1ad9f55a006e54063589f060f73944b5e515f2775e2eeb ccfd41d22148902dc18235e83fb2eeb3a8bb73ae318ca2d04ea6fdd847a9545a af002ae9995e72c137124fb02e02a50118ca7dcf62960c5d87351cf195ff76f0 6d2deb595f8d77dead21767c50bbfc095a0a18e742fe09a6d97e7751bfc3402f aa70b2e524d4efd7c4da1595b46e13ff87ba2d987c1d79eb05179d6ae8aaf8cd d47aa2b53da9239b94143f1008e1822d8b377645b83c2020be3eb4f523d87c19 1299c5d0a0bf8587b01359babac3c0029fcb311ef691c9e427da333a4151d44b 7c3db9f66e092affdd506397cada6b79bab14f8634663024f5f7f21f25b37624 68053523a66f25840e1a8283fc2f48f1ce856111ab4635c21d1213951a26c3a9 b8a41f8a852ae87ecb32b041587eeafd116d5a58ea36fc70b33dcb62fcb0c96a 2458597e09dd3b06141138940ff06791cd3c472f339115f5411bbd3362b718f8 932dc06e28c93e91c9417342d24d33e4f4264ae44e92cad8944314a1b96c2daf 2bb7ef46c469890b66b6fab82bf526cb0f781e119a422aba738930da957e2292 59bb03c3f45cada7246d3949796c60733237fbaec5ea2e957f7446e9d936065a Authentication Path for Bottom Tree: 08e46991453103f18e3fad715a1ee9722440399f35f1c0be6e43bbfb984fe670 6f2ba45e4078d06b385812cc7ca8b73ea41e15661bc4182d91d0fb4ec40ab0ff Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 21] Internet-Draft Stateful HBS for DNSSEC March 2022 7e6f17cefdfb09360bf183cd32d0b9d32fe16ea20b6bb1abe5c7acfbb589e7c6 f39d542b5c74d0a7b77c70419816332749ccffff8c854159d7929413b4fd673c f76e1b6601f603f04edc23ff1dcec725c5500f6b083f908cc273e82eebbc7fe6 a18bb4dee65e0ab6128619f5c411c45839e43df97709e4c1e5a88a5cc9232396 4e709f4758ca57a940c87900a6057390faca73a0260306916f9ec42305e75651 2d7077a6e685bad7d5ee0296a6a112be13571367d3fd11e6c439ace40836c8dc 314036534f18e26615f1139688a77762e69d3d406b4f3dfbf56234a541e67646 54ea5d084175b5bb08bcfff1609759da4d0a423b45ed57e85ea03facac460c0e Reduced signature for top tree: OTS signature: e6cd04196a939601c32d716d11877738762232a23fb3647f0fc420b4a729cfec 023c83550ea7578d72d7cf2232ec894cdf5bc403ab57bbc49e35715ccac8f744 db5adc0beb546c132d5b65448227ee0e92facdedf571922c7ab0e537cd427272 7cc76d9fed41888f57bbbd772761341d50476b001e69ec2e192195062cd473cc 6a25787c0e45a04d17628ed06a29f6ef63972daa366d5b72191f0489bb29db14 75668bcfdccec6b29a3e5c055ee0e1a2f300273a5e031a53a0357d9f4427ca27 9456a75c4250c4287f8a4ddb735210bd5ba0ec554f8d38afdf2a75f7218179d5 344a51d572239e6a6d303c0ddf1bbdd1a2fe9bcc7a7cd22858818360b3b30431 4162ab31cbd7921b115144720e88cda90849595e45e99e9a724f03371a7bc67f 1c82d7526c7f228908bcc39e41c62ddc74da5d02d7ed3cd8da8d80217ff5407a 4b08a66ab73714f7579aa55905d6ee66583ddbaf019d32593741ae03a61a9e39 efb84006f79b08ee20b6a5c8178a102e22a9cc39634e452b335e53b594ee6b3c 542cdc9ab4e1f20a7365c63b7f81d7a1618ba58b26e62b2d7a198594a8b4735a 1e662e7304a45f3fa6cff5c819a382a474b528c3e04a48e86b2b995670e0322c 9ad77adee0e4288a696cad4d45797f19ee36226f0a3a2db6ee904d2d72480251 d36bb0a6e6d8d41c0bb350fd6d105e0998824b4da7c2e447228c753da3afe8a3 b8b1d716fbf0a9e414c497241fbd5d6e6e0bf2c10cc20551c0d7192db9ede418 506207aba37b3db17d5ad4d747ba5602870e63e30b2c50fe3be527b5638f038e 33d9d5bf04b4a83a03a90d1d7e464596c25d03b62f5b59a55785f22b0387e450 e445f66d30a300839bac74f13f6eee5bdb547c694f5d35aa9a85398fde18f8f2 f678d60b2cbc638ab06f2c3d380f2bb9715514ef42b83cf02a488b52f4e247c7 95776fc26880f7624a296ef606b291a8ad3a564b724351449b77e5ef62c8282d 30657e1df7995609b374c39ec2b2e110e74b83ca54e8081d416d30e53e810458 5f99b9a652feb0770cde1b40a15804382cb9a244949a5b5936e24b55afd8dc2c bcf961c0b4d70106b640feb50039c8bb1315e8df4c819b3bae41d63c9861e760 059b78d17ee5ce381ef128293e0cfc4449a98e3de6febb558fc0368c1c95b2f2 28b1a50bc185fe21920cc4fedc192744ec97429744f932a55ee6d4294ad6a7a2 ea9d171886ffe5670a663821766572a97288bb7ebe4127e7337143752984b76b 517fad9cb887d0ed4ce53dcda00dbae32fdbd279cd322904909ca803802c53c6 3d350ad33231163cc99b8b9ff4f2a64d0d9b71da7d9851ec7027b32fddd2810d 90ec0a5eaab546267138e7a610ab2780ff23eaf714914139067640f00b299a67 227a3f8f69bc25baecfe1b3b379cf345bce38ce2e45b8ab5ee070ed35bfb41b4 0a055f1a70123c4cb02bf10ce13f450a72e8eb9f2ea07f2ad3ee497bf07bb63f 5ba263bef7e51a76ecdfc95ef98a6c3639051205f18a94e2df4ab13b3fff1962 b0f168da3322bde049b85105e0d88ec7a7fb4357d17b21694e62f6c21d0128b5 334f0e6c4d76e7915c8f376200d8cea616e9d1094124c18d888133dedeb12223 4af7fb824475953e3164e32846881ab7d793cca72f73f919fbc43fa9519fd03e Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 22] Internet-Draft Stateful HBS for DNSSEC March 2022 b413ae0d9bf77144d5f3b0e8c00b39e9131ea2682226de722efe632901c892af ef1e2e06fb45807e5d478ca273363b37780fb1f76fba538a9bfa5e87bd094676 3432beb34ca37c870c99623d4ec106f81d1fa4c258c953fd15f024e311a39b0e 5d6a6973759d62141fe64e3d0341e2ec59805433fbe371f189eba3354acc1fce 8a46f728882542e48a03184a02760f812422754a181da1a8ee182cd4a0c78a8d 2445ff9465dd2d6ad87529a3c8f4f8d79f75f89a01f7f495d735f9c4c962e51b f2e9c50dd270964f4551268c8fdb7be5db2fe9ec6b77917bb18817064fe7926c 78395d83e4420ba170a748eda61918fa3c76f25da5b458a2981ca83a7a52ec3c 356bc4059ac0a16b24663ee02fde785c5369beef7af0c79850053a2d6a12c1ed 50ebb565782dc3615f3ed71fcd133cbfa51e9c094226a04c7ef83e30459b7699 b1e0ae37e1e95ec90cb9a9d3608c79bd1445d7d9340635ab8550d42828dd6e00 4a4cb676b11cbffca1eb71a00d647e67462638d727007d0671a482fdbe68e0f9 42fdfa3439095d623461a3f0949e57cf73915b3d481d97061eba8dd860c3de46 37803bdbf0ce51136f77b2bd4ed6381f1356f7c9cc4216017574f36df10d5d24 e20ff367183ceed81d8cdbc69768ac66aa0af1408234eabbb6e1dc4020cc90c6 b4583e6e9bd31eb403ae20dfb3d37cb2f8c12e220ad6396348ac11e8f3cd5876 bb2cc448efec748ccfe3cb176f274ac20f7651e0459001aff573e9713afd2f66 ba6e0dacd9d585b20ed50f6f097177e63884fecaea83a3f93754b04163353bde 62f5c0f29d86ba73f557174d894e70fe6e433fd298dc952ef2920eb7d701877a 0d3c064c4ca260e809c8bbfe5ad8755250773d1e844485ac4b83aa7fbfd18996 1afca658f0fab1caedb698a5e5ee2ca57251ba63141b08009ca5d65887917282 9e84f3afc1051d5459b1a222c111a9cd72fbdf3d7db2160881f047dd08fea134 55899c958e250e9b376b29245742226a19a6098641ba07f0ee2054f9f41a9e70 1208d009525335ff544ccdb6cebaa8d831439177ab1f2f81665048e70e204275 4a5f92c957cbfe4110e01d1bdd3d91eb06e73ff4f1e2302f7f584a3cf92c70e0 78221dd30bbc6cd16160f22df659256501d9a4259972670288abeb8daa49ed46 a9ee360c44ad65f812708b3d720389a994975b23518c12548cf3ae9e1b6d2104 050ead89f035da5c13e9a311b529687b7a5bc91f0514764ed77abfd5b45f80fc df0ab24cccc6523df5f8bb8da0a0b32e135cee05f0d707003ec25812d3b54d66 35417bbcbe43afb6d31173620ed3a46b37d8339de8bf366c83bf6f886505c596 Authentication Path for Top Tree: 5c2110e8f14b28dc1d03855e91b3481054ce024914abedc61e5476c269b54345 767fbeb11c4d93107104dd2e1d36dc3ee5ca52c44928cde3723c2643a473be1f 4a5056676cd0545450e3c66d445946345e5bbbadb67d84cda2d8544357802560 aa205cae00c9dc36617a936686b106a2a80d561b3b237c302896506346c59fe5 a71f2d7dde085c01ab91902322fee318ebba00fbb50ca5b88f0b5bf2b18f51b2 8aac80b38d0675bbeded4ac1e45359699717ead9a6543748743a4d2ef6309be3 e218c317997188f29152cce28f4cdeed7ef719e320791b5676f41542a66d4dbd 53af4eda8cd2866d4c558ece2f2c0cd2c6519133e8b0325d153ffadabcc74474 48108ff2cf84f343fbb165cd7ebe3b424ea165f14d5ff2a2a1644ddbe8718f1f 8ae76ddb1b0522b43c5ad085767431a6f4fe472a18a9ab20bf0f430601725e6c Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 23] Internet-Draft Stateful HBS for DNSSEC March 2022 7. IANA Considerations This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entries are requested to be added to the registry: HSS/LMS +--------------+--------------------+ | Number |TBD | | Description |HSS/LMS | | Mnemonic |HSSLMS | | Zone Signing | Y | | Trans. Sec. | * | | Reference | This specification | +--------------+--------------------+ XMSS +--------------+--------------------+ | Number |TBD | | Description |XMSS | | Mnemonic |XMSS | | Zone Signing | Y | | Trans. Sec. | * | | Reference | This specification | +--------------+--------------------+ XMSS^MT +--------------+--------------------+ | Number |TBD | | Description | XMSS^MT. | | Mnemonic | XMSSMT. | | Zone Signing | Y | | Trans. Sec. | * | | Reference | This specification | +--------------+--------------------+ * There has been no determination of standardization of the use of these algorithms with Transaction Security. [LMSREGISTRY] and [XMSSREGISTRY] 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 [LMSREGISTRY]. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 24] Internet-Draft Stateful HBS for DNSSEC March 2022 HSS/LMS refers to allowable LMS OTS algorithm signature identifiers. These identifiers are found in the IANA "LM-OTS Signatures" registry [LMSREGISTRY]. 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 [XMSSREGISTRY]. Separate algorithm identifiers for XMSS and XMSS^MT are needed so that the appropriate registry in [XMSSREGISTRY] 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 [XMSSREGISTRY]. 8. Implementation Status 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 9. Security Considerations 9.1. Guidelines for Secure Use of Hash-Based Signature Algorithms HSS/LMS, XMSS and XMSS^MT as defined here MUST use 256-bit or larger hash algorithms. 256-bit hash sizes are consistent with a desired minimum 128-bit security level for HSS/LMS, XMSS and XMSS^MT per [EATON] [SPHINCSPLUS]. The HSS/LMS public key MUST be generated in conformance with Section 4 of [NISTSP800208]. 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 [RFC8391]. 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 re-use of OTS private keys may provide an attacker with key information that enables forging of signatures. A detailed discussion of the vulnerabilities re-use of OTS private keys enables is described in [OOPS]. Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 25] Internet-Draft Stateful HBS for DNSSEC March 2022 The requirement that OTS private keys may only be used once creates the need for state management to assure OTS keys are not re-used. 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 [NISTSP800208]. 9.2. NIST SP 800-208 Compliance The requirements in this section apply to implementations subject to [NISTSP800208]. OTS private keys for hash-based algorithms MUST NOT be exported from a cryptographic module. In adherence to this operational constraint, OTS private keys for individual sub-trees in a hierarchical Merkle Tree structure including the top-level tree MUST be generated, stored and used within a single cryptographic module and MUST NOT be exported. In [NISTSP800208] NIST provides guidance and requirements for multi- tree hash-based algorithms implemented across distributed "cryptographic modules". Per 7.2. of [NISTSP800208], 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 [NISTSP800208] therefore MUST use the algorithms specified in 7.2. of [NISTSP800208]. NIST's approach is to have the cryptographic modules for each tree level simply implement a single-tree signature scheme, with the signer combining the outputs of the different cryptographic modules into a multi-level 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 [NISTSP800208]. 10. Acknowledgements 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 11. Normative References Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 26] Internet-Draft Stateful HBS for DNSSEC March 2022 [DNSSECREGISTRY] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", April 2020, . [LMSREGISTRY] IANA, "Leighton-Micali Signature (LMS)", June 2021, . [NISTSP800171] National Institute of Standards and Technology (NIST), "SP 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations", February 2020, . [NISTSP800208] National Institute of Standards and Technology (NIST), "SP 800-208 Recommendation for Stateful Hash-Based Signature Schemes", October 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 27] Internet-Draft Stateful HBS for DNSSEC March 2022 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, "XMSS: eXtended Merkle Signature Scheme", RFC 8391, DOI 10.17487/RFC8391, May 2018, . [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, April 2019, . [XMSSREGISTRY] IANA, "XMSS: Extended Hash-Based Signatures", May 2020, . 12. Informative References [EATON] Eaton, E., "Leighton-Micali Hash-Based Signatures in the Quantum Random-Oracle Model", Cryptology ePrint Archive, Report 2017/607, 2017, . [FLAGDAY2020] Surý, O., "DNS Flag Day 2020", September 2020, . [FUJIWARA] Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop- avoid-fragmentation-05, June 2021, . [HUELSING13] Huelsing, A., "W-OTS+ - Shorter Signatures for Hash-Based Signature Schemes", Lecture Notes in Computer Science, Volume 7918, Progress in Cryptology - AFRICACRYPT, January 2018, . [MERKLE1979] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Technical Report No. 1979-1, June 1979, . [MERKLE1989] Merkle, R., "A Certified Digital Signature", Advances in Cryptology - CRYPTO '89, 9th Annual International Cryptology Conference, 1989, . Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 28] Internet-Draft Stateful HBS for DNSSEC March 2022 [OOPS] Bruinderink, L. G. and A. Huelsing, ""Oops, I Did It Again" - Security of One-Time Signatures Under Two-Message Attacks", SAC 2017. SAC 2017. Lecture Notes in Computer Science, vol 10719. Springer, Cham., August 2017, . [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, . [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, . [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, . [RFC8708] Housley, R., "Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 8708, DOI 10.17487/RFC8708, February 2020, . [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", RFC 8778, DOI 10.17487/RFC8778, April 2020, . [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, . Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 29] Internet-Draft Stateful HBS for DNSSEC March 2022 Appendix A. Change Log Authors' Addresses Andrew Fregly Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: afregly@verisign.com URI: http://www.verisignlabs.com/ Roland Martijn van Rijswijk-Deij DACS group, EEMCS, University of Twente DRIENERLOLAAN 5 7522 NB ENSCHEDE Netherlands Email: r.m.vanrijswijk@utwente.nl URI: https://people.utwente.nl/r.m.vanrijswijk Fregly & van Rijswijk-DeExpires 3 September 2022 [Page 30]