--- 1/draft-ietf-dnsop-dns-zone-digest-05.txt 2020-04-08 12:13:13.138323190 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-06.txt 2020-04-08 12:13:13.174323701 -0700 @@ -1,23 +1,23 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Standards Track M. Weinberg -Expires: September 10, 2020 Verisign +Expires: October 10, 2020 Verisign W. Kumari Google W. Hardaker USC/ISI - March 9, 2020 + April 8, 2020 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-05 + draft-ietf-dnsop-dns-zone-digest-06 Abstract This document describes a protocol and new DNS Resource Record that can be used to provide 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 an 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 September 10, 2020. + This Internet-Draft will expire on October 10, 2020. 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 @@ -89,46 +89,46 @@ 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 10 3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11 3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11 3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 3.6. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15 6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15 - 6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16 + 6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 15 7. Performance Considerations . . . . . . . . . . . . . . . . . 16 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25 - A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 26 + A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 25 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27 - A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 28 - A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 27 + A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 on disk in the so-called master file format [RFC1034]. Zones are generally distributed among name servers using the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can also be distributed outside of the DNS, with such protocols as FTP, HTTP, rsync, and even via email. Currently there is no standard way @@ -174,21 +174,21 @@ DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another protocol extension designed to authenticate individual DNS transactions. Whereas SIG records were originally designed to 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 is also designed to provide channel security. One can easily imagine the distribution of zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS - [dns-over-https], and perhaps even a future version of DNS-over-TLS + [RFC8484], and perhaps even a future version of DNS-over-TLS ([RFC7858]). Unfortunately, the protections provided by these channel security techniques are (in practice) ephemeral and are not retained after the data transfer is complete. They can 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 @@ -436,35 +436,35 @@ 3. Calculating the Digest 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. 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 serves two purposes: (1) it allows the digest to cover the - Serial, Scheme, and Hash Algorithm fields, and (2) ensures that - appropriate denial-of-existence (NSEC, NSEC3) records are created if - the zone is signed with DNSSEC. When multiple ZONEMD RRs are - published in the zone, e.g., during an algorithm rollover, each must - specify a unique Scheme and Hash Algorithm tuple. + This ensures that appropriate denial-of-existence (NSEC, NSEC3) + records are created if the zone is signed with DNSSEC. When multiple + ZONEMD RRs are published in the zone, e.g., during an 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. 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. The Digest field is set to all zeroes and - of length appropriate for the chosen hash algorithm. + 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. Implementations MAY want to set the + Digest field to all zeroes anyway. 3.2. Optionally Sign the Zone Following addition of placeholder records, the zone may be signed with DNSSEC. Note that 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. @@ -500,21 +500,21 @@ 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 Occluded data ([RFC5936] Section 3.5) MUST be included. o Only one instance of duplicate RRs with equal owner, class, type and RDATA SHALL be included ([RFC4034] Section 6.3). - o The placeholder ZONEMD RR(s) MUST be included. + o The placeholder 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. 3.5. Scheme-Specific Processing At this time, only the SIMPLE collation scheme is defined. Additional schemes may be defined in future updates to this document. @@ -555,76 +555,67 @@ at the same time. 4. Verifying Zone Digest The recipient of a zone that has a ZONEMD RR can verify 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. - 1. The verifier MUST first determine whether or not to expect - DNSSEC records in the zone. This can be 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 can not be performed, - digest validation continues at step 4 below. + 1. The verifier MUST first determine whether or not to expect DNSSEC + records in the zone. This can be 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 can not be performed, digest validation + 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 be done. 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 verification MUST NOT be considered successful. 4. If the ZONEMD RRSet contains more than one RR with the same Scheme and Hash Algorithm, digest verification MUST NOT be considered successful. - 5. The SOA Serial field MUST exactly match the ZONEMD Serial field. - If the fields to not match, digest verification MUST NOT be - considered successful. - - 6. The ZONEMD Hash Algorithm field MUST be checked. If the - verifier does not support the given Hash Algorithm, it SHOULD - report that the zone digest could not be verified due to an - unsupported algorithm. - - 7. The received Digest value is copied to a temporary location. - Repeat for each ZONEMD RR present. + 5. Loop over all apex ZONEMD RRs and perform the following steps: - 8. The ZONEMD RR's Digest field MUST be set to all zeroes. Repeat - for each RR present in the apex ZONEMD RRSet, even for - unsupported Scheme and Hash Algorithm values. + A. The SOA Serial field MUST exactly match the ZONEMD Serial + field. If the fields do not match, digest verification MUST + NOT be considered successful with this ZONEMD RR. - 9. The zone digest is computed over the zone data as described in - Section 3.5. + B. The Scheme field MUST be checked. If the verifier does not + support the given scheme, it SHOULD report that the RR's + digest could not be verified due to an unsupported scheme. - 10. The calculated digest is compared to the received digest stored - in the temporary location. If the two digest values match, - verification is considered successful. Otherwise, verification - MUST NOT be considered successful. + C. The Hash Algorithm field MUST be checked. If the verifier + does not support the given hash algorithm, it SHOULD report + that the RR's digest could not be verified due to an + unsupported algorithm. - 11. The ZONEMD RR's RDATA is reset to the received Digest stored in - the temporary location. Thus, any downstream clients can - similarly verify the zone. + D. The zone digest is computed over the zone data as described + in Section 3.5, using the Scheme and Hash Algorithm for the + current ZONEMD RR. - Note that when multiple ZONEMD RRs are present in the zone, the - Digest field of each MUST be zeroed in step 8 above, even for - unsupported Scheme and Hash Algorithm values. + E. 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. 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 Value: 63 @@ -1034,20 +1025,30 @@ o Specifciation Required for updates to ZONEMD protocol registries. o Other rewording based on WGLC feedback. o Updated RFC numbers for some references. o Use documentation IP addresses instead of loopback. o Updated examples in the appendix. + From -05 to -06: + + o Per WG suggestion, no longer include any apex ZONEMD record in + digest calculation. + + o Updated examples in the appendix. + + o Clarified verification procedure by describing a loop over all + ZONEMD RRs. + 12. References 12.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, @@ -1071,26 +1072,20 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [CZDS] Internet Corporation for Assigned Names and Numbers, "Centralized Zone Data Service", October 2018, . - [dns-over-https] - Hoffman, P. and P. McManus, "DNS Queries over HTTPS - (DoH)", draft-ietf-doh-dns-over-https-12 (work in - progress), June 2018, . - [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, @@ -1146,20 +1141,24 @@ [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, . [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), @@ -1180,100 +1179,83 @@ A.1. Simple EXAMPLE Zone Here, the EXAMPLE zone contains an SOA record, NS and glue records, and a ZONEMD record. example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) 86400 IN NS ns1 86400 IN NS ns2 86400 IN ZONEMD 2018031900 1 1 ( - e12a0dd55a1dd1b8 - e29ec9b1d42d71ec - 09329da5f162f327 - e1eb4803947995ec - f7c65aa566cf6cfd - 36a0caf8bdb03ac4 ) + c68090d90a7aed71 + 6bc459f9340e3d7c + 1370d4d24b7e2fc3 + a1ddc0b9a87153b9 + a9713b3c9ae5cc27 + 777f98b8e730044c ) ns1 3600 IN A 203.0.113.63 ns2 3600 IN AAAA 2001:db8::63 A.2. Complex EXAMPLE Zone Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, and one out-of-zone RR. example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) 86400 IN NS ns1 86400 IN NS ns2 86400 IN ZONEMD 2018031900 1 1 ( - 626637812169d7ab - fcb24f13cb704f13 - b8a131fee1c3bc73 - 29144fa5ec2608a4 - 1b596d41ff8c8310 - b2897e73f6e521fc ) + 31cefb03814f5062 + ad12fa951ba0ef5f + 8da6ae354a415767 + 246f7dc932ceb1e7 + 42a2108f529db6a3 + 3a11c01493de358d ) ns1 3600 IN A 203.0.113.63 ns2 3600 IN AAAA 2001:db8::63 occluded.sub 7200 IN TXT "I'm occluded but must be digested" sub 7200 IN NS ns1 duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once" foo.test. 555 IN TXT "out-of-zone data must be excluded" non-apex 900 IN ZONEMD 2018031900 1 1 ( 616c6c6f77656420 6275742069676e6f 7265642e20616c6c 6f77656420627574 2069676e6f726564 2e20616c6c6f7765 ) A.3. EXAMPLE Zone with multiple digests Here, the EXAMPLE zone contains multiple ZONEMD records. Since only - one Hash Algorithm is defined at this time (SHA384), this example - utilizes additional ZONEMD records with Hash Algorithm values in the - private range (240-254). These additional private-range digests are - not verifiable, but note that their other fields (Serial, Scheme, - Hash Algorithm) are included in the calculation of all ZONEMD - digests. + one Scheme (SIMPLE) and one Hash Algorithm (SHA384) is defined at + this time, this example utilizes additional ZONEMD records with + Scheme and Hash Algorithm values in the private range (240-254). + These additional private-range digests are not verifiable. example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) example. 86400 IN NS ns1.example. example. 86400 IN NS ns2.example. example. 86400 IN ZONEMD 2018031900 1 1 ( - 366d22ea3bd8df44 - 0fa44b6213359d9b - 1f73bb9d8dd67a1b - 4c0bdf6f0b3657c5 - 0316f770fbb03057 - 0c06adb87c121431 ) + 62e6cf51b02e54b9 + b5f967d547ce4313 + 6792901f9f88e637 + 493daaf401c92c27 + 9dd10f0edb1c56f8 + 080211f8480ee306 ) example. 86400 IN ZONEMD 2018031900 1 240 ( e2d523f654b9422a 96c5a8f44607bbee ) - example. 86400 IN ZONEMD 2018031900 1 241 ( - 5732dd91240611f8 - 314adb6b4769bdd2 ) - example. 86400 IN ZONEMD 2018031900 1 242 ( - 7c32e06779315c7d - 81ba8c72f5cf9116 - 496b6395 ) - example. 86400 IN ZONEMD 2018031900 1 243 ( - 183770af4a629f80 - 2e674e305b8d0d11 - 3dfe0837 ) - example. 86400 IN ZONEMD 2018031900 1 244 ( - e1846540e33a9e41 - 89792d18d5d131f6 - 05fc283e ) - example. 86400 IN ZONEMD 2018031900 240 1 ( + example. 86400 IN ZONEMD 2018031900 241 1 ( e1846540e33a9e41 89792d18d5d131f6 05fc283e ) ns1.example. 3600 IN A 203.0.113.63 ns2.example. 86400 IN TXT "This example has multiple digests" ns2.example. 3600 IN AAAA 2001:db8::63 A.4. The URI.ARPA Zone The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has @@ -1408,22 +1389,22 @@ NSEC ) urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( "/urn:([^:]+)/\\1/i" . ) uri.arpa. 3600 IN SOA sns.dns.icann.org. ( noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) ;; Query time: 66 msec ;; SERVER: 192.0.32.132#53(192.0.32.132) ;; WHEN: Sun Oct 21 20:39:28 UTC 2018 ;; XFR size: 34 records (messages 1, bytes 3941) uri.arpa. 3600 IN ZONEMD 2018100702 1 1 ( - cc4a0b6556272fc739b8ff74b80b4a43ac9575d91445ecc0dc22f5 - 09fa27c62448a7100660bbdb4c90667424b734956b ) + 1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa + dc556439889a10eaf6f11d615900a4f996bd46279514e473 ) A.5. The ROOT-SERVERS.NET Zone The ROOT-SERVERS.NET zone retreived 2018-10-21. root-servers.net. 3600000 IN SOA a.root-servers.net. ( nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) root-servers.net. 3600000 IN NS a.root-servers.net. root-servers.net. 3600000 IN NS b.root-servers.net. root-servers.net. 3600000 IN NS c.root-servers.net. @@ -1461,22 +1442,22 @@ j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 m.root-servers.net. 3600000 IN A 202.12.27.33 root-servers.net. 3600000 IN SOA a.root-servers.net. ( nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 ( - 4fb752b314e4dccb845832b611590b669a80daebb736d4bd22aa76ec06 - 6737c79185c1f7dfd49ec91d9523e6240ea2c4 ) + f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97 + 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 ) Authors' Addresses Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 Phone: +1 703 948-3200 Email: dwessels@verisign.com