--- 1/draft-ietf-dnsop-dns-zone-digest-13.txt 2020-10-15 10:13:14.822164442 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-14.txt 2020-10-15 10:13:14.898166370 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Standards Track Verisign -Expires: April 12, 2021 M. Weinberg +Expires: April 18, 2021 M. Weinberg Amazon W. Kumari Google W. Hardaker USC/ISI - October 9, 2020 + October 15, 2020 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-13 + draft-ietf-dnsop-dns-zone-digest-14 Abstract This document describes a protocol and new DNS Resource Record that 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 @@ -43,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 12, 2021. + This Internet-Draft will expire on April 18, 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 @@ -82,90 +82,92 @@ 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 . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 10 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 + 2.5. Including ZONEMD RRs in a Zone . . . . . . . . . . . . . 10 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 11 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 11 - 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11 + 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 12 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.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 13 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 + 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 16 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 + 6.6. Resilience and Fragility . . . . . . . . . . . . . . . . 18 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27 - Appendix A. Example Zones With Digests . . . . . . . . . . . . . 29 - A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 29 + Appendix A. Example Zones With Digests . . . . . . . . . . . . . 30 + A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 30 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 + A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 32 + A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 35 + Appendix B. Implementation Status . . . . . . . . . . . . . . . 37 + B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 37 + B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 37 + B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 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. + zone to verify the zone's integrity and authenticity when used in + combination with DNSSEC. 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. 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. + The primary 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 @@ -344,27 +346,20 @@ Required are to be interpreted as defined in [RFC8126]. 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]. [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 a placeholder RR. @@ -398,42 +393,44 @@ 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 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. + Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme + defined for ZONEMD records and it MUST be supported by + implementations. 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 - SHA384 is used, the size of the Digest field is 48 octets. The - result of the SHA384 digest algorithm MUST NOT be truncated, and the - entire 48 octet digest is published in the ZONEMD record. + Herein, SHA384 [RFC6234], with Hash Algorithm value 1, is the only + standardized Hash Algorithm defined for ZONEMD records that MUST be + supported by implementations. When SHA384 is used, the size of the + Digest field is 48 octets. The result of the SHA384 digest algorithm + MUST NOT be truncated, and the entire 48 octet digest is published in + the ZONEMD record. SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for - ZONEMD records, and SHOULD be implemented. When SHA512 is used, the - size of the Digest field is 64 octets. The result of the SHA512 - digest algorithm MUST NOT be truncated, and the entire 64 octet - digest is published in the ZONEMD record. + ZONEMD records, and SHOULD be supported by implementations. When + SHA512 is used, the size of the Digest field is 64 octets. The + result of the SHA512 digest algorithm MUST NOT be truncated, and the + entire 64 octet digest is published in the ZONEMD record. Hash Algorithm values 240-254 are allocated for Private Use. The Hash Algorithm registry is further described in Section 5. 2.2.4. The Digest Field The Digest field is a variable-length sequence of octets containing the output of the hash algorithm. The length of the Digest field is determined by deducting the fixed size of the Serial, Scheme, and @@ -465,28 +462,43 @@ text. 2.4. ZONEMD Example The following example shows a ZONEMD RR in presentation format: example.com. 86400 IN ZONEMD 2018031500 1 1 ( FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) +2.5. Including ZONEMD RRs in a Zone + + The zone operator chooses an appropriate hash algorithm and scheme, + and includes the calculated zone digest in the apex ZONEMD RRset. + The zone operator MAY choose any of the defined hash algorithms and + schemes, including the private use code points. + + The ZONEMD RRSet MAY contain multiple records to support algorithm + agility [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 operator is in the process of + transitioning to a new scheme or hash algorithm. + 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. + described algorithm are advised to ensure that it produces ZONEMD + RRs, signatures, and dential-of-existence records that are identical + to the ones generated by this procedure. 3.1. Add ZONEMD Placeholder 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 @@ -591,81 +603,74 @@ 4. Verifying Zone Digest 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, 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. + records in the zone. By examining locally configured trust + anchors, and, if necessary, querying for and validating DS RRs in + the parent zone, the verifier knows whether or not the zone to be + verified should include DNSSEC keys and signatures. For zones + where signatures are not expected, 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. + 2. For zones where signatures are expected, the existence of the + apex ZONEMD record MUST be validated. If the DNSSEC data proves + the ZONEMD RRSet does not exist, digest verification cannot + occur. If the DNSSEC data proves the ZONEMD does 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 + 3. For zones where signatures are expected, the SOA and ZONEMD + RRSets MUST have valid signatures, chaining up to a trust anchor. + If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest verification MUST NOT be considered successful. 4. When multiple ZONEMD RRs are present, each MUST specify a unique Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains more than one RR with the same Scheme and Hash Algorithm, digest verification for those ZONEMD RRs MUST NOT be considered successful. 5. Loop over all apex ZONEMD RRs and perform the following steps: 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. B. The Scheme field MUST be checked. If the verifier does not support the given scheme, 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 - scheme. + successful with this ZONEMD RR. C. The Hash Algorithm field MUST be checked. If the verifier 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. + NOT be considered successful with this ZONEMD RR. 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 due to an incorrect digest - length. + with this ZONEMD RR. 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 @@ -1206,20 +1212,36 @@ 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. + From -13 to -14: + + o A few more edits and clarifications from IESG reviewer comments. + + o Moved paragraph about multiple digests to new section titled + Including ZONEMD RRs in a Zone. + + o MUST be implemented -> MUST be supported by implementations. + + o Consolidated SHOULD requirements about error reporting to single + place at the conclusion of verification. + + o Rephrased "provably insecure" etc as using DNSSEC validation to + know whether or not the zone is expected to have keys and + signatures. + 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,