--- 1/draft-ietf-dnsop-dns-zone-digest-12.txt 2020-10-09 15:13:22.715449990 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-13.txt 2020-10-09 15:13:22.803452219 -0700 @@ -1,34 +1,36 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Standards Track Verisign -Expires: April 2, 2021 M. Weinberg +Expires: April 12, 2021 M. Weinberg Amazon W. Kumari Google W. Hardaker USC/ISI - September 29, 2020 + October 9, 2020 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-12 + draft-ietf-dnsop-dns-zone-digest-13 Abstract This document describes a protocol and new DNS Resource Record that - provides a cryptographic message digest over DNS zone data. The - ZONEMD Resource Record conveys the digest data in the zone itself. - When a zone publisher includes a ZONEMD record, recipients can verify - the zone contents for accuracy and completeness. This provides - assurance that received zone data matches published data, regardless - of how the zone data has been transmitted and received. + provides a cryptographic message digest over DNS zone data at rest. + The ZONEMD Resource Record conveys the digest data in the zone + itself. When used in combination with DNSSEC, ZONEMD allows + recipients to verify the zone contents for data integrity and origin + authenticity. This provides assurance that received zone data + matches published data, regardless of how the zone data has been + transmitted and received. When used without DNSSEC, ZONEMD functions + as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. @@ -41,21 +43,21 @@ 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 April 2, 2021. + This Internet-Draft will expire on April 12, 2021. Copyright Notice Copyright (c) 2020 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 @@ -66,158 +68,166 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Alternative Approaches . . . . . . . . . . . . . . . . . 4 1.3. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 1.4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 - 1.4.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 + 1.4.2. Providers, Secondaries, and Anycast . . . . . . . . . 7 1.4.3. Response Policy Zones . . . . . . . . . . . . . . . . 7 1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.4.5. General Purpose Comparison Check . . . . . . . . . . 7 - 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 - 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 + 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 + 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 8 2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 - 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 + 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 - 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 + 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 10 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 - 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10 - 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 + 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 11 + 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 11 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11 - 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 - 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11 - 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11 + 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 12 + 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 + 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 12 3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12 - 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 - 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 - 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 13 + 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 13 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 15 + 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 15 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16 - 6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16 - 6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16 - 6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17 - 7. Performance Considerations . . . . . . . . . . . . . . . . . 17 - 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17 - 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 11.2. Informative References . . . . . . . . . . . . . . . . . 25 - Appendix A. Example Zones With Digests . . . . . . . . . . . . . 28 - A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 28 - A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28 - A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29 - A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 30 - A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 33 - Appendix B. Implementation Status . . . . . . . . . . . . . . . 35 - B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 35 - B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 35 - B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 6.1. Using Zone Digest Without DNSSEC . . . . . . . . . . . . 16 + 6.2. Attacks Against the Zone Digest . . . . . . . . . . . . . 16 + 6.3. Use of Multiple ZONEMD Hash Algorithms . . . . . . . . . 17 + 6.4. DNSSEC Timing Considerations . . . . . . . . . . . . . . 17 + 6.5. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 17 + 6.6. Resilience and Fragility . . . . . . . . . . . . . . . . 17 + 7. Performance Considerations . . . . . . . . . . . . . . . . . 18 + 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 11.2. Informative References . . . . . . . . . . . . . . . . . 27 + Appendix A. Example Zones With Digests . . . . . . . . . . . . . 29 + A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 29 + A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 30 + A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 31 + A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 31 + A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 34 + Appendix B. Implementation Status . . . . . . . . . . . . . . . 36 + B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 36 + B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 36 + B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction In the DNS, a zone is the collection of authoritative resource records (RRs) sharing a common origin ([RFC8499]). Zones are often stored as files in the so-called master file format [RFC1034]. Zones are generally distributed among name servers using the AXFR (zone transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995]) protocols. They can also be distributed outside of the DNS, with any file transfer protocol such as FTP, HTTP, and rsync, or even as email - attachments. Currently there is no standard way to verify the - authenticity of a stand-alone zone. + attachments. Currently, there is no standard way to compute a hash + or message digest for a stand-alone zone. This document specifies an RR type that provides a cryptographic message digest of the data in a zone. It allows a receiver of the zone to verify the zone's integrity, and when used in combination with DNSSEC, its authenticity. The digest RR is a part of the zone itself, allowing verification of the zone, no matter how it is transmitted. The digest uses the wire format of zone data in a canonical ordering. Thus, it is independent of presentation format, such as whitespace, capitalization, and comments. This specification is OPTIONAL to implement by both publishers and consumers of zone data. - DNSSEC provides three strong security guarantees relevant to this - protocol: +1.1. Motivation + + The motivation for this protocol enhancement is the desire to verify + the data integrity and origin authenticity of a stand-alone zone, + regardless of how it is transmitted. A consumer of zone data should + be able to verify that it is as-published by the zone operator. + + Note, however, that integrity and authenticity can only be assured + when the zone is signed. DNSSEC provides three strong security + guarantees relevant to this protocol: 1. whether or not to expect DNSSEC records in the zone, 2. whether or not to expect a ZONEMD record in a signed zone, and 3. whether or not the ZONEMD record has been altered since it was signed. -1.1. Motivation - - The motivation for this protocol enhancement is the desire to verify - the authenticity of a stand-alone zone, regardless of how it is - transmitted. A consumer of zone data should be able to verify that - the data is as-published by the zone operator. + A secondary motivation is to provide the equivalent of a checksum, + allowing a zone recipient to check for unintended changes and + operational errors, such as accidental truncation. 1.2. Alternative Approaches One approach to preventing data tampering and corruption is to secure the distribution channel. The DNS has a number of features that are already used for channel security. Perhaps the most widely used is DNS transaction signatures (TSIG [RFC2845]). TSIG uses shared secret keys and a message digest to protect individual query and response messages. It is generally used to authenticate and validate UPDATE [RFC2136], AXFR [RFC5936], and IXFR [RFC1995] messages. DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another protocol extension that authenticates individual DNS transactions. Whereas SIG records normally cover specific RR types, SIG(0) is used to sign an entire DNS message. Unlike TSIG, SIG(0) uses public key cryptography rather than shared secrets. The Transport Layer Security protocol suite also provides channel - security. One can easily imagine the distribution of zones over - HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484], and - perhaps even a future version of DNS-over-TLS ([RFC7858]). + security. The DPRIVE working group is in the process of specifying + DNS Zone Transfer-over-TLS [I-D.ietf-dprive-xfr-over-tls]. One can + also easily imagine the distribution of zones over HTTPS-enabled web + servers, as well as DNS-over-HTTPS [RFC8484]. Unfortunately, the protections provided by these channel security techniques are (in practice) ephemeral and are not retained after the data transfer is complete. They ensure that the client receives the data from the expected server, and that the data sent by the server is not modified during transmission. However, they do not guarantee that the server transmits the data as originally published, and do not provide any methods to verify data that is read after transmission is complete. For example, a name server loading saved zone data upon restart cannot guarantee that the on-disk data has not been modified. Such modification could be the result of an accidental corruption of the file, or perhaps an incompletely saved file [disk-full-failure]. For these reasons, it is preferable to - secure the data itself. + protect the integrity of the data itself. Why not simply rely on DNSSEC, which provides certain data security guarantees? For zones that are signed, a recipient could validate all of the signed RRSets. Additionally, denial-of-existence records prove that RRSets have not been added or removed. However, delegations (non-apex NS records) are not signed by DNSSEC, and neither are any glue records. ZONEMD protects the integrity of delegation, glue, and other records that are not otherwise covered by - DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are - susceptible to the removal or addition of names between the signed - nodes. Whereas DNSSEC is primarily protects consumers of DNS + DNSSEC. Furthermore, zones that employ NSEC3 with opt-out [RFC5155] + are susceptible to the removal or addition of names between the + signed nodes. Whereas DNSSEC primarily protects consumers of DNS response messages, this protocol protects consumers of zones. There are existing tools and protocols that provide data security, such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the internic.net site publishes PGP signatures alongside the root zone and other files available there. However, this is a detached signature with no strong association to the corresponding zone file other than its timestamp. Non-detached signatures are, of course, possible, but these necessarily change the format of the file being distributed; a zone signed with OpenPGP or S/MIME no longer looks @@ -243,25 +253,25 @@ message digest of the content of a zone. The digest is calculated at the time of zone publication. If the zone is signed with DNSSEC, any modifications of the digest can be detected. The procedures for digest calculation and DNSSEC signing are similar. Both require data to be processed in a well-defined order and format. It may be possible to perform DNSSEC signing and digest calculation in parallel. The zone digest is designed to be used on zones that have infrequent updates. As specified herein, the digest is re-calculated over the - entire zone content each time. This specification does not provide - an efficient mechanism for updating the digest on incremental updates - of zone data. It is, however, extensible so future schemes to - support incremental zone digest algorithms (e.g. using Merkle trees) - can be accommodated. + entire zone content each time the zone is updated. This + specification does not provide an efficient mechanism for updating + the digest on incremental updates of zone data. It is, however, + extensible so that future schemes may be defined to support efficient + incremental digest updates. It is expected that verification of a zone digest will be implemented in name server software. That is, a name server can verify the zone data it was given and refuse to serve a zone which fails verification. For signed zones, the name server needs a trust anchor to perform DNSSEC validation. For signed non-root zones, the name server may need to send queries to validate a chain of trust. Digest verification could also be performed externally. 1.4. Use Cases @@ -276,52 +286,58 @@ time. [RFC8806] describes one way to do this. As the root zone spreads beyond its traditional deployment boundaries, the verification of the completeness of the zone contents becomes more important. 1.4.2. Providers, Secondaries, and Anycast Since its very early days, the developers of the DNS recognized the importance of secondary name servers and service diversity. However, modern DNS service has complex provisioning which includes multiple - third-party providers and hundreds of anycast instances. Instead of - a simple primary-to-secondary zone distribution system, today it is - possible to have multiple levels, multiple parties, and multiple - protocols involved in the distribution of zone data. This complexity - introduces new places for problems to arise. The zone digest - protects the integrity of data that flows through such systems. + third-party providers ([RFC8901]) and hundreds of anycast instances + ([RFC3258]). Instead of a simple primary-to-secondary zone + distribution system, today it is possible to have multiple levels, + multiple parties, and multiple protocols involved in the distribution + of zone data. This complexity introduces new places for problems to + arise. The zone digest protects the integrity of data that flows + through such systems. 1.4.3. Response Policy Zones - DNS Response Policy Zones is "a method of expressing DNS response - policy information inside specially constructed DNS zones..." [RPZ]. - A number of companies provide RPZ feeds, which are consumed by name + A Response Policy Zone (RPZ) is "a mechanism to introduce a + customized policy in Domain Name System servers, so that recursive + resolvers return possibly modified results" [RPZ]. The policy + information is carried inside specially constructed DNS zones. A + number of companies provide RPZ feeds, which are consumed by name server and firewall products. While RPZ zones can be signed with DNSSEC, the data is not queried directly, and would not be subject to DNSSEC validation. 1.4.4. Centralized Zone Data Service ICANN operates the Centralized Zone Data Service [CZDS], which is a repository of top-level domain zone files. Users that have been granted access are then able to download zone data. Adding a zone digest to these would provide CZDS users with assurances that the - data has not been modified between origination and retrieval. ZONEMD - could be added to CZDS zone data independently of the zone served by - production name servers. + data has not been modified between origination and retrieval. Note + that ZONEMD could be added to zone data supplied to CZDS without + requiring it to be present in the zone data served by production name + servers, since the digest is inherently attached to the specific copy + of the zone. 1.4.5. General Purpose Comparison Check Since the zone digest calculation does not depend on presentation format, it could be used to compare multiple copies of a zone received from different sources, or copies generated by different - processes. + processes. In this case, it serves as a checksum and can be useful + even for unsigned zones. 1.5. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms Private Use, Reserved, Unassigned, and Specification @@ -329,25 +345,25 @@ 2. The ZONEMD Resource Record This section describes the ZONEMD Resource Record, including its fields, wire format, and presentation format. The Type value for the ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of the resource record consists of four fields: Serial, Scheme, Hash Algorithm, and Digest. A zone MAY contain multiple ZONEMD RRs to support algorithm agility - [RFC7696] and rollovers. When multiple ZONEMD RRs are present, each - must specify a unique Scheme and Hash Algorithm tuple. It is - RECOMMENDED that a zone include only one ZONEMD RR, unless the zone - publisher is in the process of transitioning to a new Scheme or Hash - Algorithm. + [RFC7696]. [RFC Editor: change that to BCP 201] When multiple ZONEMD + RRs are present, each MUST specify a unique Scheme and Hash Algorithm + tuple. It is RECOMMENDED that a zone include only one ZONEMD RR, + unless the zone publisher is in the process of transitioning to a new + Scheme or Hash Algorithm. 2.1. Non-apex ZONEMD Records This document specifies ZONEMD RRs located at the zone apex. Non- apex ZONEMD RRs are not forbidden, but have no meaning in this specification. Non-apex ZONEMD RRs MUST NOT be used for verification. During digest calculation, non-apex ZONEMD RRs are treated as ordinary RRs. They are digested as-is and the RR is not replaced by @@ -382,23 +398,23 @@ version of the zone's content. Without the serial number, a stand- alone ZONEMD digest has no obvious association to any particular instance of a zone. 2.2.2. The Scheme Field The Scheme field is an 8-bit unsigned integer that identifies the methods by which data is collated and presented as input to the hashing function. - Herein, SIMPLE, with value 1, is the only standardized Scheme defined - for ZONEMD records and it MUST be implemented. The Scheme registry - is further described in Section 5. + Herein, SIMPLE, with Hash Algorithm value 1, is the only standardized + Scheme defined for ZONEMD records and it MUST be implemented. The + Scheme registry is further described in Section 5. Scheme values 240-254 are allocated for Private Use. 2.2.3. The Hash Algorithm Field The Hash Algorithm field is an 8-bit unsigned integer that identifies the cryptographic hash algorithm used to construct the digest. Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash Algorithm defined for ZONEMD records that MUST be implemented. When @@ -451,24 +467,32 @@ 2.4. ZONEMD Example The following example shows a ZONEMD RR in presentation format: example.com. 86400 IN ZONEMD 2018031500 1 1 ( FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 3. Calculating the Digest + The algorithm described in this section is designed for the common + case of offline DNSSEC signing. Slight deviations may be permitted + or necessary in other situations, such as with unsigned zones or + online DNSSEC signing. Implementations that deviate from the + described algorithm are advised to ensure that identical ZONEMD RRs, + signatures, and dential-of-existence records are produced. + 3.1. Add ZONEMD Placeholder - In preparation for calculating the zone digest, any existing ZONEMD - records (and covering RRSIGs) at the zone apex are first deleted. + In preparation for calculating the zone digest(s), any existing + ZONEMD records (and covering RRSIGs) at the zone apex are first + deleted. Prior to calculation of the digest, and prior to signing with DNSSEC, one or more placeholder ZONEMD records are added to the zone apex. This ensures that denial-of-existence (NSEC, NSEC3) records are created correctly if the zone is signed with DNSSEC. If placeholders were not added prior to signing, the later addition of ZONEMD records would also require updating the Type Bit Maps field of any apex NSEC/ NSEC3 RRs, which then invalidates the calculated digest value. When multiple ZONEMD RRs are published in the zone, e.g., during an @@ -501,33 +525,34 @@ schemes may be defined in future updates to this document. 3.3.1. The SIMPLE Scheme For the SIMPLE scheme, the digest is calculated over the zone as a whole. This means that a change to a single RR in the zone requires iterating over all RRs in the zone to recalculate the digest. SIMPLE is a good choice for zones that are small and/or stable, but probably not good for zones that are large and/or dynamic. - Calculation of a zone digest REQUIRES RRs to be processed in a + Calculation of a zone digest requires RRs to be processed in a consistent format and ordering. This specification uses DNSSEC's canonical on-the-wire RR format (without name compression) and ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with the additional provision that RRSets having the same owner name MUST be numerically ordered, in ascending order, by their numeric RR TYPE. 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules When iterating over records in the zone, the following inclusion/ exclusion rules apply: - o All records in the zone, including glue records, MUST be included. + o All records in the zone, including glue records, MUST be included, + unless excluded by a subsequent rule. o Occluded data ([RFC5936] Section 3.5) MUST be included. o If there are duplicate RRs with equal owner, class, type, and RDATA, only one instance is included ([RFC4034] Section 6.3), and the duplicates MUST be omitted. o The placeholder apex ZONEMD RR(s) MUST NOT be included. o If the zone is signed, DNSSEC RRs MUST be included, except: @@ -567,24 +592,25 @@ The recipient of a zone that has a ZONEMD RR verifies the zone by calculating the digest as follows. If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Schemes and Hash Algorithms is sufficient to verify the zone. The verifier MAY ignore a ZONEMD RR if its Scheme and Hash Algorithm violates local policy. 1. The verifier MUST first determine whether or not to expect DNSSEC records in the zone. This is done by examining locally - configured trust anchors, or querying for (and validating) DS RRs - in the parent zone. For zones that are provably insecure, or if - DNSSEC validation is not performed, digest verification continues - at step 4 below. + configured trust anchors, and, if necessary, querying for (and + validating) DS RRs in the anchors, or querying for (and + validating) DS RRs in the parent zone. For zones that are + provably insecure, or if DNSSEC validation is not performed, + digest verification continues at step 4 below. 2. For zones that are provably secure, the existence of the apex ZONEMD record MUST be verified. If the ZONEMD record provably does not exist, digest verification cannot occur. If the ZONEMD record does provably exist, but is not found in the zone, digest verification MUST NOT be considered successful. 3. For zones that are provably secure, the SOA and ZONEMD RRSets MUST have valid signatures, chaining up to a trust anchor. If DNSSEC validation of the SOA or ZONEMD records fails, digest @@ -624,20 +650,27 @@ E. The zone digest is computed over the zone data as described in Section 3.3, using the Scheme and Hash Algorithm for the current ZONEMD RR. F. The computed digest is compared to the received digest. If the two digest values match, verification is considered successful. Otherwise, verification MUST NOT be considered successful for this ZONEMD RR. + [ Maybe remove all the "SHOULD report" above and just say this:] + + Each time zone verification is performed, the verifier SHOULD report + the status as either successful or unsuccessful. When unsuccessful, + the verifier SHOULD report the reason(s) that verification did not + succeed. + 5. IANA Considerations 5.1. ZONEMD RRtype This document defines a new DNS RR type, ZONEMD, whose value 63 has been allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry: Type: ZONEMD @@ -650,32 +683,30 @@ 5.2. ZONEMD Scheme IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: Registry Name: ZONEMD Schemes Registration Procedure: Specification Required Reference: [this document] - +---------+---------------+----------+------------------+-----------+ - | Value | Description | Mnemonic | Implementation | Reference | - | | | | Requirement | | - +---------+---------------+----------+------------------+-----------+ - | 0 | Reserved | | | | - | 1 | Simple ZONEMD | SIMPLE | MUST | [this | - | | collation | | | document] | - | 2-239 | Unassigned | | | | - | 240-254 | Private Use | N/A | N/A | [this | - | | | | | document] | - | 255 | Reserved | | | | - +---------+---------------+----------+------------------+-----------+ + + +---------+-------------------------+----------+-----------------+ + | Value | Description | Mnemonic | Reference | + +---------+-------------------------+----------+-----------------+ + | 0 | Reserved | | | + | 1 | Simple ZONEMD collation | SIMPLE | [this document] | + | 2-239 | Unassigned | | | + | 240-254 | Private Use | N/A | [this document] | + | 255 | Reserved | | | + +---------+-------------------------+----------+-----------------+ Table 1: ZONEMD Scheme Registry 5.3. ZONEMD Hash Algorithm IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: Registry Name: ZONEMD Hash Algorithms @@ -673,91 +704,108 @@ Table 1: ZONEMD Scheme Registry 5.3. ZONEMD Hash Algorithm IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: Registry Name: ZONEMD Hash Algorithms Registration Procedure: Specification Required - Reference: [this document] - +---------+-------------+----------+-------------------+------------+ - | Value | Description | Mnemonic | Implementation | Reference | - | | | | Requirement | | - +---------+-------------+----------+-------------------+------------+ - | 0 | Reserved | | | | - | 1 | SHA-384 | SHA384 | MUST | [this | - | | | | | document] | - | 2 | SHA-512 | SHA512 | SHOULD | [this | - | | | | | document] | - | 3-239 | Unassigned | | | | - | 240-254 | Private Use | N/A | N/A | [his | - | | | | | document] | - | 255 | Reserved | | | | - +---------+-------------+----------+-------------------+------------+ + +---------+-------------+----------+-----------------+ + | Value | Description | Mnemonic | Reference | + +---------+-------------+----------+-----------------+ + | 0 | Reserved | | | + | 1 | SHA-384 | SHA384 | [this document] | + | 2 | SHA-512 | SHA512 | [this document] | + | 3-239 | Unassigned | | | + | 240-254 | Private Use | N/A | [his document] | + | 255 | Reserved | | | + +---------+-------------+----------+-----------------+ Table 2: ZONEMD Hash Algorithm Registry 6. Security Considerations -6.1. Attacks Against the Zone Digest - The zone digest allows the recipient of a zone to verify its - integrity. In conjunction with DNSSEC, the recipient can - authenticate that it is as published by the zone originator. +6.1. Using Zone Digest Without DNSSEC + + Users of ZONEMD with unsigned zones are advised that it provides no + real protection against attacks. While zone digests can be used in + the absence of DNSSEC, this only provides protection against + accidental zone corruption, such as transmission errors and + truncation. When used in this manner, it effectively serves only as + a checksum. For zones not signed with DNSSEC, an attacker can make + any zone modifications appear to be valid by recomputing Digest field + of a ZONEMD RR. + +6.2. Attacks Against the Zone Digest An attacker, whose goal is to modify zone content before it is used by the victim, may consider a number of different approaches. The attacker might perform a downgrade attack to an unsigned zone. This is why Section 4 talks about determining whether or not to expect DNSSEC signatures for the zone in step 1. The attacker might perform a downgrade attack by removing one or more ZONEMD records. Such a removal is detectable only with DNSSEC validation and is why Section 4 talks about checking denial-of- existence proofs in step 2 and signature validation in step 3. The attacker might alter the Scheme, Hash Algorithm, or Digest fields of the ZONEMD record. Such modifications are detectable only with DNSSEC validation. -6.2. DNSSESC Timing Considerations + As stated in [RFC7696], cryptographic algorithms age and become + weaker as cryptanalysis techniques and computing resources improve + with time. Implementors and publishers of zone digests should + anticipate the need for algorithm agility on long timescales. + +6.3. Use of Multiple ZONEMD Hash Algorithms + + When a zone publishes multiple ZONEMD RRs, the overall security is + only as good as the weakest hash algorithm in use. For this reason, + Section 2 recommends only publishing multiple ZONEMD RRs when + transitioning to a new scheme or hash algorithm. Once the transition + is complete, the old scheme or hash algorithm should be removed from + the ZONEMD RRSet. + +6.4. DNSSEC Timing Considerations As with all DNSSEC signatures, the ability to perform signature validation of a ZONEMD record is limited in time. If the DS record(s) or trust anchors for the zone to be verified are no longer available, the recipient cannot validate the ZONEMD RRSet. This could happen even if the ZONEMD signature is still current (not expired), since the zone's DS record(s) may have been withdrawn following a Key Signing Key (KSK) rollover. For zones where it may be important to validate a ZONEMD RRSet through its entire signature validity period, the zone operator should ensure that KSK rollover timing takes this into consideration. -6.3. Attacks Utilizing ZONEMD Queries +6.5. Attacks Utilizing ZONEMD Queries Nothing in this specification prevents clients from making, and servers from responding to, ZONEMD queries. Servers SHOULD NOT calculate zone digests dynamically (for each query) as this can be used as a CPU resource exhaustion attack. ZONEMD responses could be used in a distributed denial-of-service amplification attack. The ZONEMD RR is moderately sized, much like the DS RR. A single ZONEMD RR contributes approximately 65 to 95 octets to a DNS response, for digest types defined herein. Other RR types, such as DNSKEY, can result in larger amplification effects. -6.4. Resilience and Fragility +6.6. Resilience and Fragility ZONEMD is used to detect incomplete or corrupted zone data prior to its use, thereby increasing resilience by not using corrupt data, but also introduces some denial-of-service fragility by making good data in a zone unavailable if some other data is missing or corrupt. Publishers and consumers of zones containing ZONEMD records should be aware of these tradeoffs. While the intention is to secure the zone data, misconfigurations or implementation bugs are generally indistinguishable from intentional tampering, and could lead to service failures when verification is performed automatically. @@ -821,21 +869,22 @@ 9. Acknowledgments The authors wish to thank David Blacka, Scott Hollenbeck, and Rick Wilhelm for providing feedback on early drafts of this document. Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul - Wouters, and other members of the DNS working group for their input. + Wouters, and other members of the DNSOP working group for their + input. 10. Change Log RFC Editor: Please remove this section before publication. This section lists substantial changes to the document as it is being worked on. From -00 to -01: @@ -1131,20 +1180,46 @@ o SECDIR review: Forgot to delete sentence about IANA policy for adding new hash algorithms. o SECDIR review: Spell out Key Signing Key first time. o SECDIR review: say "private use hash algorithm code points." o SECDIR review: Update estimates of ZONEMD RR size. + From -12 to -13: + + o Added reference to draft-ietf-dprive-xfr-over-tls. + + o Dropped Implementation Requirement from registry tables. + + o Added Use of Multiple ZONEMD Hash Algorithms to Security + Considerations. + + o Added Using Zone Digest Without DNSSEC to Security Considerations. + + o Added notes about the need for algorithm agility due to crypto + algorithm aging. + + o Further clarified that only with DNSSEC can ZONEMD guarantee + integrity and authenticity. + + o For unsigned zones, ZONEMD serves only as a checksum. + + o Calculation algorithm is designed for common case of offline + signing. Deviations may be allowed as long as the end result is + the same. + + o Numerous small edits and clarifications from IESG reviewer + comments. + 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, @@ -1179,20 +1254,25 @@ DENIC, "Background of the Partial Failure of the Name Service for .de Domains", May 2010, . [DnsTools] NIC Chile Labs, "DNS tools for zone signature (file, pkcs11-hsm) and validation, and zone digest (ZONEMD)", April 2020, . + [I-D.ietf-dprive-xfr-over-tls] + Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. + Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- + xfr-over-tls-02 (work in progress), July 2020. + [InterNIC] ICANN, "InterNIC FTP site", May 2018, . [ldns-zone-digest] Verisign, "Implementation of Message Digests for DNS Zones using the ldns library", July 2018, . [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, @@ -1214,69 +1294,77 @@ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, . [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, . + [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via + Shared Unicast Addresses", RFC 3258, DOI 10.17487/RFC3258, + April 2002, . + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, + . + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . - [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., - and P. Hoffman, "Specification for DNS over Transport - Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May - 2016, . - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, . + [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. + Blacka, "Multi-Signer DNSSEC Models", RFC 8901, + DOI 10.17487/RFC8901, September 2020, + . + [RootServers] Root Server Operators, "Root Server Technical Operations", July 2018, . - [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones - (RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress), - June 2018, . + [RPZ] Wikipedia, "Response policy zone", May 2020, + . [ZoneDigestHackathon] Kerr, S., "Prototype implementation of ZONEMD for the IETF 102 hackathon in Python", July 2018, . Appendix A. Example Zones With Digests This appendix contains example zones with accurate ZONEMD records. These can be used to verify an implementation of the zone digest @@ -1566,29 +1654,28 @@ nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 ( f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 ) Appendix B. Implementation Status RFC Editor: Please retain this section upon publication. 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 + protocol defined by this specification at the time of publication, + and is inspired by the concepts described in RFC7942. + + 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. B.1. Authors' Implementation The authors have an open source implementation in C, using the ldns library [ldns-zone-digest]. This implementation is able to perform the following functions: o Read an input zone and output a zone with the ZONEMD placeholder.