--- 1/draft-ietf-dnsop-dns-zone-digest-11.txt 2020-09-29 10:13:18.004529250 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-12.txt 2020-09-29 10:13:18.076531079 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Standards Track Verisign -Expires: March 29, 2021 M. Weinberg +Expires: April 2, 2021 M. Weinberg Amazon W. Kumari Google W. Hardaker USC/ISI - September 25, 2020 + September 29, 2020 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-11 + draft-ietf-dnsop-dns-zone-digest-12 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. @@ -41,21 +41,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 March 29, 2021. + This Internet-Draft will expire on April 2, 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 @@ -93,44 +93,44 @@ 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.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 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25 - Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27 - A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27 + 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 . . . . . . . . . . . . . . . . . . . . 29 - A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32 - Appendix B. Implementation Status . . . . . . . . . . . . . . . 34 - B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34 - B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34 - B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 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 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 @@ -331,21 +331,21 @@ 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 + 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. @@ -371,23 +371,24 @@ / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2.1. The Serial Field The Serial field is a 32-bit unsigned integer in network byte order. It is the serial number from the zone's SOA record ([RFC1035] section 3.3.13) for which the zone digest was generated. - It is included here in order to make DNS response messages of type - ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD - digest has no association to any particular instance of a zone. + It is included here to clearly bind the ZONEMD RR to a particular + 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. @@ -474,23 +475,23 @@ algorithm rollover, each MUST specify a unique Scheme and Hash Algorithm tuple. It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of the SOA. However, the TTL of the ZONEMD record may be safely ignored during verification in all cases. In the placeholder record, the Serial field is set to the current SOA Serial. The Scheme field is set to the value for the chosen collation scheme. The Hash Algorithm field is set to the value for - the chosen hash algorithm. Since ZONEMD records are excluded from - digest calculation, the value of the Digest field does not matter at - this point in the process. + the chosen hash algorithm. Since apex ZONEMD records are excluded + from digest calculation, the value of the Digest field does not + matter at this point in the process. 3.2. Optionally Sign the Zone Following addition of placeholder records, the zone may be signed with DNSSEC. When the digest calculation is complete, and the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet MUST be recalculated and updated as well. Therefore, the signer is not required to calculate a signature over the placeholder record at this step in the process, but it is harmless to do so. @@ -520,26 +521,27 @@ exclusion rules apply: o All records in the zone, including glue records, MUST be included. 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 ZONEMD RR(s) MUST NOT be included. + o The placeholder apex ZONEMD RR(s) MUST NOT be included. o If the zone is signed, DNSSEC RRs MUST be included, except: - o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG - will be updated after all digests have been calculated. + o The RRSIG covering the apex ZONEMD RRSet MUST NOT be included + because the RRSIG will be updated after all digests have been + calculated. 3.3.1.2. SIMPLE Scheme Digest Calculation A zone digest using the SIMPLE scheme is calculated by concatenating all RRs in the zone, in the format and order described in Section 3.3.1 subject to the inclusion/exclusion rules described in Section 3.3.1.1, and then applying the chosen hash algorithm: digest = hash( RR(1) | RR(2) | RR(3) | ... ) @@ -610,21 +612,21 @@ does not support the given hash algorithm, verification MUST NOT be considered successful with this ZONEMD RR and it SHOULD report that the RR's digest could not be verified due to an unsupported algorithm. D. The Digest field size MUST be checked. If the size of the given Digest field is smaller than 12 octets, or if the size is not equal to the size expected for the corresponding Hash Algorithm, verification MUST NOT be considered successful with this ZONEMD RR and the verifier SHOULD report that the - RR's digest could not be verified to to an incorrect digest + RR's digest could not be verified due to an incorrect digest length. 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. @@ -691,25 +693,21 @@ | 2 | SHA-512 | SHA512 | SHOULD | [this | | | | | | document] | | 3-239 | Unassigned | | | | | 240-254 | Private Use | N/A | N/A | [his | | | | | | document] | | 255 | Reserved | | | | +---------+-------------+----------+-------------------+------------+ Table 2: ZONEMD Hash Algorithm Registry - The IANA policy for assigning new values to the ZONEMD Hash Algorithm - registry shall be Specification Required. - 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. 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. @@ -726,53 +724,53 @@ DNSSEC validation. 6.2. DNSSESC 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 KSK rollover. + 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 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 40 to 65 + 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 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. Zone publishers may want to deploy ZONEMD gradually, perhaps by - utilizing one of the private use hash algorithms listed in + utilizing one of the private use hash algorithm code points listed in Section 5.3. Similarly, recipients may want to initially configure verification failures only as a warning, and later as an error after gaining experience and confidence with the feature. 7. Performance Considerations This section is provided to make zone publishers aware of the performance requirements and implications of including ZONEMD RRs in a zone. @@ -1114,20 +1112,39 @@ o Fixed people's names in the acknowledgments section (blush) o Say "has not been modified between origination and retrieval." o Say that ZONEMD TTL doesn't matter during verification. o Further clarification that the SHA-384 and SHA-512 hashes are not truncated. Future algs might be truncated, but never below 96 bits. + From -11 to -12: + + o SECDIR review: make "recommended" all caps. + + o SECDIR review: tweak explanation of why ZONEMD RR has copy of SOA + serial. + + o SECDIR review: be even more clear about apex ZONEMD RRs vs non- + apex. + + 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. + 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,