--- 1/draft-ietf-dnsop-dns-zone-digest-00.txt 2019-09-05 17:13:22.915599518 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-01.txt 2019-09-05 17:13:22.975601042 -0700 @@ -1,23 +1,23 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Experimental M. Weinberg -Expires: December 26, 2019 Verisign +Expires: March 8, 2020 Verisign W. Kumari Google W. Hardaker USC/ISI - June 24, 2019 + September 5, 2019 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-00 + draft-ietf-dnsop-dns-zone-digest-01 Abstract This document describes an experimental protocol and new DNS Resource Record that can be used to provide a message digest over DNS zone data. The ZONEMD Resource Record conveys the message 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 @@ -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 December 26, 2019. + This Internet-Draft will expire on March 8, 2020. Copyright Notice Copyright (c) 2019 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 @@ -91,36 +91,36 @@ 3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10 3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11 4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12 4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 - 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15 + 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15 - 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 16 + 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 15 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19 - Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22 + Appendix A. Example Zones With Digests . . . . . . . . . . . . . 21 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction In the DNS, a zone is the collection of authoritative resource @@ -575,31 +575,22 @@ verification is considered successful. Otherwise, verification MUST NOT be considered successful. 12. The ZONEMD RR's RDATA is reset to the received Digest Type and Digest stored in the temporary location. Thus, any downstream clients can similarly verify the zone. 4.1. Verifying Multiple Digests If multiple digests are present in the zone, e.g., during an - algorithm rollover, at least one of the recipient's supported Digest - Type algorithms MUST verify the zone. - - It is RECOMMENDED that implementations maintain a (possibly - configurable) list of supported Digest Type algorithms ranked from - most to least preferred. It is further RECOMMENDED that recipients - use only their most preferred algorithm that is present in the zone - for digest verification. - - As a matter of local policy, the recipient MAY require that all - supported and present Digest Type algorithms verify the zone. + algorithm rollover, a match using any one of the recipient's + supported Digest Type algorithms is sufficient to verify the zone. 5. Scope of Experimentation This memo is published as an Experimental RFC. The purpose of the experimental period is to provide the community time to analyze and evaluate the methods defined in this document, particularly with regard to the wide variety of DNS zones in use on the Internet. Additionally, the ZONEMD record defined in this document includes a Reserved field in the form of an 8-bit integer. The authors have a @@ -706,40 +696,35 @@ o Read an input zone and output a zone with the ZONEMD placeholder. o Compute zone digest over signed zone and update the ZONEMD record. o Re-compute DNSSEC signature over the ZONEMD record. o Verify the zone digest from an input zone. This implementation does not: - o Perform DNSSEC validation of the ZONEMD record. - - o Support the Gost digest algorithm. - - o Output the ZONEMD record in its defined presentation format. + o Perform DNSSEC validation of the ZONEMD record during + verification. 10.2. Shane Kerr's Implementation Shane Kerr wrote an implementation of this specification during the IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in Python and is able to perform the following functions: o Read an input zone and a output zone with ZONEMD record. o Verify the zone digest from an input zone. o Output the ZONEMD record in its defined presentation format. - o Generate Gost digests. - This implementation does not: o Re-compute DNSSEC signature over the ZONEMD record. o Perform DNSSEC validation of the ZONEMD record. 11. Change Log RFC Editor: Please remove this section. @@ -858,20 +843,30 @@ o Adopted by dnsop. o Clarified further that non-apex ZONEMD RRs have no meaning. o Changed "provably [un]signed" to "provably [in]secure". o Allow multiple ZONEMD RRs to support algorithm agility/rollovers. o Describe verification when there are multiple ZONEMD RRs. + From -00 to -01: + + o Simplified requirements around verifying multiple digests. Any + one match is sufficient. + + o Updated implementation notes. + + o Both implementations produce expected results on examples given in + this document. + 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,