draft-ietf-dnsop-dns-zone-digest-10.txt   draft-ietf-dnsop-dns-zone-digest-11.txt 
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Standards Track Verisign Intended status: Standards Track Verisign
Expires: March 25, 2021 M. Weinberg Expires: March 29, 2021 M. Weinberg
Amazon Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
September 21, 2020 September 25, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-10 draft-ietf-dnsop-dns-zone-digest-11
Abstract Abstract
This document describes a protocol and new DNS Resource Record that This document describes a protocol and new DNS Resource Record that
provides a cryptographic message digest over DNS zone data. The provides a cryptographic message digest over DNS zone data. The
ZONEMD Resource Record conveys the digest data in the zone itself. ZONEMD Resource Record conveys the digest data in the zone itself.
When a zone publisher includes a ZONEMD record, recipients can verify When a zone publisher includes a ZONEMD record, recipients can verify
the zone contents for accuracy and completeness. This provides the zone contents for accuracy and completeness. This provides
assurance that received zone data matches published data, regardless assurance that received zone data matches published data, regardless
of how the zone data has been transmitted and received. of how the zone data has been transmitted and received.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2021. This Internet-Draft will expire on March 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7
1.4.5. General Purpose Comparison Check . . . . . . . . . . 7 1.4.5. General Purpose Comparison Check . . . . . . . . . . 7
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8 2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8
2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10
2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11
3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11
3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12 3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12
3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15 6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16
6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16 6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16
6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16 6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16
6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 16 6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17
7. Performance Considerations . . . . . . . . . . . . . . . . . 17 7. Performance Considerations . . . . . . . . . . . . . . . . . 17
7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32
Appendix B. Implementation Status . . . . . . . . . . . . . . . 34 Appendix B. Implementation Status . . . . . . . . . . . . . . . 34
B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34 B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34
B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34 B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34
B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35 B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
skipping to change at page 7, line 24 skipping to change at page 7, line 24
server and firewall products. While RPZ zones can be signed with 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, the data is not queried directly, and would not be subject to
DNSSEC validation. DNSSEC validation.
1.4.4. Centralized Zone Data Service 1.4.4. Centralized Zone Data Service
ICANN operates the Centralized Zone Data Service [CZDS], which is a ICANN operates the Centralized Zone Data Service [CZDS], which is a
repository of top-level domain zone files. Users that have been repository of top-level domain zone files. Users that have been
granted access are then able to download zone data. Adding a zone granted access are then able to download zone data. Adding a zone
digest to these would provide CZDS users with assurances that the digest to these would provide CZDS users with assurances that the
data has not been modified. ZONEMD could be added to CZDS zone data data has not been modified between origination and retrieval. ZONEMD
independently of the zone served by production name servers. could be added to CZDS zone data independently of the zone served by
production name servers.
1.4.5. General Purpose Comparison Check 1.4.5. General Purpose Comparison Check
Since the zone digest calculation does not depend on presentation Since the zone digest calculation does not depend on presentation
format, it could be used to compare multiple copies of a zone format, it could be used to compare multiple copies of a zone
received from different sources, or copies generated by different received from different sources, or copies generated by different
processes. processes.
1.5. Terminology 1.5. Terminology
skipping to change at page 9, line 24 skipping to change at page 9, line 28
Scheme values 240-254 are allocated for Private Use. Scheme values 240-254 are allocated for Private Use.
2.2.3. The Hash Algorithm Field 2.2.3. The Hash Algorithm Field
The Hash Algorithm field is an 8-bit unsigned integer that identifies The Hash Algorithm field is an 8-bit unsigned integer that identifies
the cryptographic hash algorithm used to construct the digest. the cryptographic hash algorithm used to construct the digest.
Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
Algorithm defined for ZONEMD records that MUST be implemented. When Algorithm defined for ZONEMD records that MUST be implemented. When
SHA384 is used, the size of the Digest field is 48 octets. 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 SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
ZONEMD records, and SHOULD be implemented. When SHA512 is used, the ZONEMD records, and SHOULD be implemented. When SHA512 is used, the
size of the Digest field is 64 octets. 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. Hash Algorithm values 240-254 are allocated for Private Use.
The Hash Algorithm registry is further described in Section 5. The Hash Algorithm registry is further described in Section 5.
2.2.4. The Digest Field 2.2.4. The Digest Field
The Digest field is a variable-length sequence of octets containing The Digest field is a variable-length sequence of octets containing
the output of the hash algorithm. The Digest field MUST NOT be the output of the hash algorithm. The length of the Digest field is
shorter than 12 octets. The length of the Digest field is determined determined by deducting the fixed size of the Serial, Scheme, and
by deducting the fixed size of the Serial, Scheme, and Hash Algorithm Hash Algorithm fields from the RDATA size in the ZONEMD RR header.
fields from the RDATA size in the ZONEMD RR header. Section 3
describes how to calculate the digest for a zone. Section 4 The Digest field MUST NOT be shorter than 12 octets. Digests for the
describes how to use the digest to verify the contents of a zone. SHA384 and SHA512 hash algorithms specified herein are never
truncated. Digests for future hash algorithms MAY be truncated, but
MUST NOT be truncated to a length that results in less than 96-bits
(12 octets) of equivalent strength.
Section 3 describes how to calculate the digest for a zone.
Section 4 describes how to use the digest to verify the contents of a
zone.
2.3. ZONEMD Presentation Format 2.3. ZONEMD Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Serial field is represented as an unsigned decimal integer. The Serial field is represented as an unsigned decimal integer.
The Scheme field is represented as an unsigned decimal integer. The Scheme field is represented as an unsigned decimal integer.
The Hash Algorithm field is represented as an unsigned decimal The Hash Algorithm field is represented as an unsigned decimal
skipping to change at page 10, line 40 skipping to change at page 11, line 6
created correctly if the zone is signed with DNSSEC. If placeholders created correctly if the zone is signed with DNSSEC. If placeholders
were not added prior to signing, the later addition of ZONEMD records 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/ would also require updating the Type Bit Maps field of any apex NSEC/
NSEC3 RRs, which then invalidates the calculated digest value. NSEC3 RRs, which then invalidates the calculated digest value.
When multiple ZONEMD RRs are published in the zone, e.g., during an When multiple ZONEMD RRs are published in the zone, e.g., during an
algorithm rollover, each MUST specify a unique Scheme and Hash algorithm rollover, each MUST specify a unique Scheme and Hash
Algorithm tuple. Algorithm tuple.
It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
the SOA. 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 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 Serial. The Scheme field is set to the value for the chosen
collation scheme. The Hash Algorithm field is set to the value for collation scheme. The Hash Algorithm field is set to the value for
the chosen hash algorithm. Since ZONEMD records are excluded from the chosen hash algorithm. Since ZONEMD records are excluded from
digest calculation, the value of the Digest field does not matter at digest calculation, the value of the Digest field does not matter at
this point in the process. this point in the process.
3.2. Optionally Sign the Zone 3.2. Optionally Sign the Zone
skipping to change at page 18, line 18 skipping to change at page 18, line 40
9. Acknowledgments 9. Acknowledgments
The authors wish to thank David Blacka, Scott Hollenbeck, and Rick The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
Wilhelm for providing feedback on early drafts of this document. Wilhelm for providing feedback on early drafts of this document.
Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul
Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt
Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis, Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis,
Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem
Toorop, Florian Weimer, Tim Wicinksi, Wouter Wijngarrds, Paul Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul
Wouters, and other members of the dnsop working group for their Wouters, and other members of the DNS working group for their input.
input.
10. Change Log 10. Change Log
RFC Editor: Please remove this section before publication. RFC Editor: Please remove this section before publication.
This section lists substantial changes to the document as it is being This section lists substantial changes to the document as it is being
worked on. worked on.
From -00 to -01: From -00 to -01:
skipping to change at page 24, line 8 skipping to change at page 24, line 28
o From SECDIR review, say that ZONEMD RRs MAY be ignored by local o From SECDIR review, say that ZONEMD RRs MAY be ignored by local
policy. policy.
o Moved Implementation Status to an appendix with the intention to o Moved Implementation Status to an appendix with the intention to
retain it in RFC. retain it in RFC.
o In registry tables, changed Status column to Implementation o In registry tables, changed Status column to Implementation
Requirement. Requirement.
From -10 to -11:
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.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
 End of changes. 16 change blocks. 
26 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/