draft-ietf-dnsop-dns-zone-digest-13.txt   draft-ietf-dnsop-dns-zone-digest-14.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: April 12, 2021 M. Weinberg Expires: April 18, 2021 M. Weinberg
Amazon Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
October 9, 2020 October 15, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-13 draft-ietf-dnsop-dns-zone-digest-14
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 at rest. provides a cryptographic message digest over DNS zone data at rest.
The ZONEMD Resource Record conveys the digest data in the zone The ZONEMD Resource Record conveys the digest data in the zone
itself. When used in combination with DNSSEC, ZONEMD allows itself. When used in combination with DNSSEC, ZONEMD allows
recipients to verify the zone contents for data integrity and origin recipients to verify the zone contents for data integrity and origin
authenticity. This provides assurance that received zone data authenticity. This provides assurance that received zone data
matches published data, regardless of how the zone data has been matches published data, regardless of how the zone data has been
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 April 12, 2021. This Internet-Draft will expire on April 18, 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 49 skipping to change at page 2, line 49
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 8 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . 9 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 10 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 10
2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10
2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
2.5. Including ZONEMD RRs in a Zone . . . . . . . . . . . . . 10
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 11 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 11
3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 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. Scheme-Specific Processing . . . . . . . . . . . . . . . 12
3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12
3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 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 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 13
4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 13 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 15 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 15
5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 15 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 15
5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Using Zone Digest Without DNSSEC . . . . . . . . . . . . 16 6.1. Using Zone Digest Without DNSSEC . . . . . . . . . . . . 16
6.2. Attacks Against the Zone Digest . . . . . . . . . . . . . 16 6.2. Attacks Against the Zone Digest . . . . . . . . . . . . . 16
6.3. Use of Multiple ZONEMD Hash Algorithms . . . . . . . . . 17 6.3. Use of Multiple ZONEMD Hash Algorithms . . . . . . . . . 17
6.4. DNSSEC Timing Considerations . . . . . . . . . . . . . . 17 6.4. DNSSEC Timing Considerations . . . . . . . . . . . . . . 17
6.5. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 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. Performance Considerations . . . . . . . . . . . . . . . . . 18
7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 18 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 18
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 29 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 30
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 29 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 30
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 30 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 30
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 31 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 31
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 31 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 32
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 34 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 35
Appendix B. Implementation Status . . . . . . . . . . . . . . . 36 Appendix B. Implementation Status . . . . . . . . . . . . . . . 37
B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 36 B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 37
B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 36 B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 37
B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 37 B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
In the DNS, a zone is the collection of authoritative resource In the DNS, a zone is the collection of authoritative resource
records (RRs) sharing a common origin ([RFC8499]). Zones are often records (RRs) sharing a common origin ([RFC8499]). Zones are often
stored as files in the so-called master file format [RFC1034]. Zones stored as files in the so-called master file format [RFC1034]. Zones
are generally distributed among name servers using the AXFR (zone are generally distributed among name servers using the AXFR (zone
transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995]) transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995])
protocols. They can also be distributed outside of the DNS, with any 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 file transfer protocol such as FTP, HTTP, and rsync, or even as email
attachments. Currently, there is no standard way to compute a hash attachments. Currently, there is no standard way to compute a hash
or message digest for a stand-alone zone. or message digest for a stand-alone zone.
This document specifies an RR type that provides a cryptographic This document specifies an RR type that provides a cryptographic
message digest of the data in a zone. It allows a receiver of the 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 zone to verify the zone's integrity and authenticity when used in
with DNSSEC, its authenticity. The digest RR is a part of the zone combination with DNSSEC. The digest RR is a part of the zone itself,
itself, allowing verification of the zone, no matter how it is allowing verification of the zone, no matter how it is transmitted.
transmitted. The digest uses the wire format of zone data in a The digest uses the wire format of zone data in a canonical ordering.
canonical ordering. Thus, it is independent of presentation format, Thus, it is independent of presentation format, such as whitespace,
such as whitespace, capitalization, and comments. capitalization, and comments.
This specification is OPTIONAL to implement by both publishers and This specification is OPTIONAL to implement by both publishers and
consumers of zone data. consumers of zone data.
1.1. Motivation 1.1. Motivation
The motivation for this protocol enhancement is the desire to verify The primary motivation for this protocol enhancement is the desire to
the data integrity and origin authenticity of a stand-alone zone, verify the data integrity and origin authenticity of a stand-alone
regardless of how it is transmitted. A consumer of zone data should zone, regardless of how it is transmitted. A consumer of zone data
be able to verify that it is as-published by the zone operator. should be able to verify that it is as-published by the zone
operator.
Note, however, that integrity and authenticity can only be assured Note, however, that integrity and authenticity can only be assured
when the zone is signed. DNSSEC provides three strong security when the zone is signed. DNSSEC provides three strong security
guarantees relevant to this protocol: guarantees relevant to this protocol:
1. whether or not to expect DNSSEC records in the zone, 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 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 3. whether or not the ZONEMD record has been altered since it was
skipping to change at page 8, line 24 skipping to change at page 8, line 24
Required are to be interpreted as defined in [RFC8126]. Required are to be interpreted as defined in [RFC8126].
2. The ZONEMD Resource Record 2. The ZONEMD Resource Record
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Scheme, Hash the resource record consists of four fields: Serial, Scheme, Hash
Algorithm, and Digest. 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 2.1. Non-apex ZONEMD Records
This document specifies ZONEMD RRs located at the zone apex. Non- This document specifies ZONEMD RRs located at the zone apex. Non-
apex ZONEMD RRs are not forbidden, but have no meaning in this apex ZONEMD RRs are not forbidden, but have no meaning in this
specification. Non-apex ZONEMD RRs MUST NOT be used for specification. Non-apex ZONEMD RRs MUST NOT be used for
verification. verification.
During digest calculation, non-apex ZONEMD RRs are treated as During digest calculation, non-apex ZONEMD RRs are treated as
ordinary RRs. They are digested as-is and the RR is not replaced by ordinary RRs. They are digested as-is and the RR is not replaced by
a placeholder RR. a placeholder RR.
skipping to change at page 9, line 34 skipping to change at page 9, line 22
version of the zone's content. Without the serial number, a stand- version of the zone's content. Without the serial number, a stand-
alone ZONEMD digest has no obvious association to any particular alone ZONEMD digest has no obvious association to any particular
instance of a zone. instance of a zone.
2.2.2. The Scheme Field 2.2.2. The Scheme Field
The Scheme field is an 8-bit unsigned integer that identifies the The Scheme field is an 8-bit unsigned integer that identifies the
methods by which data is collated and presented as input to the methods by which data is collated and presented as input to the
hashing function. hashing function.
Herein, SIMPLE, with Hash Algorithm value 1, is the only standardized Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme
Scheme defined for ZONEMD records and it MUST be implemented. The defined for ZONEMD records and it MUST be supported by
Scheme registry is further described in Section 5. implementations. The Scheme registry is further described in
Section 5.
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 Hash Algorithm value 1, is the only
Algorithm defined for ZONEMD records that MUST be implemented. When standardized Hash Algorithm defined for ZONEMD records that MUST be
SHA384 is used, the size of the Digest field is 48 octets. The supported by implementations. When SHA384 is used, the size of the
result of the SHA384 digest algorithm MUST NOT be truncated, and the Digest field is 48 octets. The result of the SHA384 digest algorithm
entire 48 octet digest is published in the ZONEMD record. 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 supported by implementations. When
size of the Digest field is 64 octets. The result of the SHA512 SHA512 is used, the size of the Digest field is 64 octets. The
digest algorithm MUST NOT be truncated, and the entire 64 octet result of the SHA512 digest algorithm MUST NOT be truncated, and the
digest is published in the ZONEMD record. 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 length of the Digest field is the output of the hash algorithm. The length of the Digest field is
determined by deducting the fixed size of the Serial, Scheme, and determined by deducting the fixed size of the Serial, Scheme, and
skipping to change at page 11, line 5 skipping to change at page 10, line 45
text. text.
2.4. ZONEMD Example 2.4. ZONEMD Example
The following example shows a ZONEMD RR in presentation format: The following example shows a ZONEMD RR in presentation format:
example.com. 86400 IN ZONEMD 2018031500 1 1 ( example.com. 86400 IN ZONEMD 2018031500 1 1 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 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 3. Calculating the Digest
The algorithm described in this section is designed for the common The algorithm described in this section is designed for the common
case of offline DNSSEC signing. Slight deviations may be permitted case of offline DNSSEC signing. Slight deviations may be permitted
or necessary in other situations, such as with unsigned zones or or necessary in other situations, such as with unsigned zones or
online DNSSEC signing. Implementations that deviate from the online DNSSEC signing. Implementations that deviate from the
described algorithm are advised to ensure that identical ZONEMD RRs, described algorithm are advised to ensure that it produces ZONEMD
signatures, and dential-of-existence records are produced. RRs, signatures, and dential-of-existence records that are identical
to the ones generated by this procedure.
3.1. Add ZONEMD Placeholder 3.1. Add ZONEMD Placeholder
In preparation for calculating the zone digest(s), any existing In preparation for calculating the zone digest(s), any existing
ZONEMD records (and covering RRSIGs) at the zone apex are first ZONEMD records (and covering RRSIGs) at the zone apex are first
deleted. deleted.
Prior to calculation of the digest, and prior to signing with DNSSEC, Prior to calculation of the digest, and prior to signing with DNSSEC,
one or more placeholder ZONEMD records are added to the zone apex. one or more placeholder ZONEMD records are added to the zone apex.
This ensures that denial-of-existence (NSEC, NSEC3) records are This ensures that denial-of-existence (NSEC, NSEC3) records are
skipping to change at page 13, line 35 skipping to change at page 13, line 46
4. Verifying Zone Digest 4. Verifying Zone Digest
The recipient of a zone that has a ZONEMD RR verifies the zone by The recipient of a zone that has a ZONEMD RR verifies the zone by
calculating the digest as follows. If multiple ZONEMD RRs are calculating the digest as follows. If multiple ZONEMD RRs are
present in the zone, e.g., during an algorithm rollover, a match present in the zone, e.g., during an algorithm rollover, a match
using any one of the recipient's supported Schemes and Hash using any one of the recipient's supported Schemes and Hash
Algorithms is sufficient to verify the zone. The verifier MAY ignore Algorithms is sufficient to verify the zone. The verifier MAY ignore
a ZONEMD RR if its Scheme and Hash Algorithm violates local policy. a ZONEMD RR if its Scheme and Hash Algorithm violates local policy.
1. The verifier MUST first determine whether or not to expect DNSSEC 1. The verifier MUST first determine whether or not to expect DNSSEC
records in the zone. This is done by examining locally records in the zone. By examining locally configured trust
configured trust anchors, and, if necessary, querying for (and anchors, and, if necessary, querying for and validating DS RRs in
validating) DS RRs in the anchors, or querying for (and the parent zone, the verifier knows whether or not the zone to be
validating) DS RRs in the parent zone. For zones that are verified should include DNSSEC keys and signatures. For zones
provably insecure, or if DNSSEC validation is not performed, where signatures are not expected, or if DNSSEC validation is not
digest verification continues at step 4 below. performed, digest verification continues at step 4 below.
2. For zones that are provably secure, the existence of the apex 2. For zones where signatures are expected, the existence of the
ZONEMD record MUST be verified. If the ZONEMD record provably apex ZONEMD record MUST be validated. If the DNSSEC data proves
does not exist, digest verification cannot occur. If the ZONEMD the ZONEMD RRSet does not exist, digest verification cannot
record does provably exist, but is not found in the zone, digest occur. If the DNSSEC data proves the ZONEMD does exist, but is
verification MUST NOT be considered successful. not found in the zone, digest verification MUST NOT be considered
successful.
3. For zones that are provably secure, the SOA and ZONEMD RRSets 3. For zones where signatures are expected, the SOA and ZONEMD
MUST have valid signatures, chaining up to a trust anchor. If RRSets MUST have valid signatures, chaining up to a trust anchor.
DNSSEC validation of the SOA or ZONEMD records fails, digest If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest
verification MUST NOT be considered successful. verification MUST NOT be considered successful.
4. When multiple ZONEMD RRs are present, each MUST specify a unique 4. When multiple ZONEMD RRs are present, each MUST specify a unique
Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains
more than one RR with the same Scheme and Hash Algorithm, digest more than one RR with the same Scheme and Hash Algorithm, digest
verification for those ZONEMD RRs MUST NOT be considered verification for those ZONEMD RRs MUST NOT be considered
successful. successful.
5. Loop over all apex ZONEMD RRs and perform the following steps: 5. Loop over all apex ZONEMD RRs and perform the following steps:
A. The SOA Serial field MUST exactly match the ZONEMD Serial A. The SOA Serial field MUST exactly match the ZONEMD Serial
field. If the fields do not match, digest verification MUST field. If the fields do not match, digest verification MUST
NOT be considered successful with this ZONEMD RR. NOT be considered successful with this ZONEMD RR.
B. The Scheme field MUST be checked. If the verifier does not B. The Scheme field MUST be checked. If the verifier does not
support the given scheme, verification MUST NOT be considered support the given scheme, verification MUST NOT be considered
successful with this ZONEMD RR and it SHOULD report that the successful with this ZONEMD RR.
RR's digest could not be verified due to an unsupported
scheme.
C. The Hash Algorithm field MUST be checked. If the verifier C. The Hash Algorithm field MUST be checked. If the verifier
does not support the given hash algorithm, verification MUST does not support the given hash algorithm, verification MUST
NOT be considered successful with this ZONEMD RR and it NOT be considered successful with this ZONEMD RR.
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 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 given Digest field is smaller than 12 octets, or if the size
is not equal to the size expected for the corresponding Hash is not equal to the size expected for the corresponding Hash
Algorithm, verification MUST NOT be considered successful Algorithm, verification MUST NOT be considered successful
with this ZONEMD RR and the verifier SHOULD report that the with this ZONEMD RR.
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 E. The zone digest is computed over the zone data as described
in Section 3.3, using the Scheme and Hash Algorithm for the in Section 3.3, using the Scheme and Hash Algorithm for the
current ZONEMD RR. current ZONEMD RR.
F. The computed digest is compared to the received digest. If F. The computed digest is compared to the received digest. If
the two digest values match, verification is considered the two digest values match, verification is considered
successful. Otherwise, verification MUST NOT be considered successful. Otherwise, verification MUST NOT be considered
successful for this ZONEMD RR. 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 Each time zone verification is performed, the verifier SHOULD report
the status as either successful or unsuccessful. When unsuccessful, the status as either successful or unsuccessful. When unsuccessful,
the verifier SHOULD report the reason(s) that verification did not the verifier SHOULD report the reason(s) that verification did not
succeed. succeed.
5. IANA Considerations 5. IANA Considerations
5.1. ZONEMD RRtype 5.1. ZONEMD RRtype
This document defines a new DNS RR type, ZONEMD, whose value 63 has This document defines a new DNS RR type, ZONEMD, whose value 63 has
skipping to change at page 26, line 25 skipping to change at page 26, line 40
o For unsigned zones, ZONEMD serves only as a checksum. o For unsigned zones, ZONEMD serves only as a checksum.
o Calculation algorithm is designed for common case of offline o Calculation algorithm is designed for common case of offline
signing. Deviations may be allowed as long as the end result is signing. Deviations may be allowed as long as the end result is
the same. the same.
o Numerous small edits and clarifications from IESG reviewer o Numerous small edits and clarifications from IESG reviewer
comments. 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. 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. 28 change blocks. 
75 lines changed or deleted 96 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/