An improvement, but still:
1.3 - general - add something like "Specifically, ZONEMD covers the
integrity of <your text here> records that are not otherwise covered by
DNSSEC".
1.3.5 - "zone digest calculation" not simply "zone digest" - this
doesn't require a ZONEMD record.
1.3.2, 1.3.3 and 1.3.4 are mostly "off-line" (not DNS in-band)
services. It's still unclear to me the value of a ZONEMD record vs
something like a hash (signed or unsigned) separately published (ala
root key down loads, or various software with published hashes) 1.3.1
may have some benefit... but still may be just another off-line service.
I think you still missed the point on Scheme/Digest mechanism. For
Scheme 1 - SIMPLE - the ancillary data is 1 byte of digest algorithm
indicator and N bytes of the actual digest per the digest, and the
digest is calculated per section 3. For scheme 2 -N - the ancillary
data is not specified, and the RR may not have a digest indicator, or
may have several indicators or fields. Describing the RRSet as Scheme
plus data, and then describing the format of the SIMPLE scheme's data
field is clearer for the extension model. That also implies that
any RRSet with a unknown scheme has to be digested as if the entire data
field (e.g. including the digest field for SIMPLE) is zeros*****.
2.1 - "Included" is confusing here. Instead "the digest is calculated
over the data as-is and the RR is not replaced by a placeholder RR.
3.1 - Could be misunderstood as written. In the second para "one or more
placeholder ZONEMD RR(s) are added (one for each digest in the SIMPLE
scheme and as many as are required to cover new schemes)". Last
paragraph becomes redundant (and it's actually multiple ZONEMD RRs not
digests).
*****(and as I think about it - what would be the harm in not including
ZONEMD placeholder records in the ZONEMD digest -e.g. just skip them?)
4.1 - move the text up before the text for 4. and delete the
subsection. Style wise, RFCs try and avoid single subsections under a
section.
Section 5 - what's the requirement to add new entries to the registries
being defined? Expert Review, RFC?
6.2 assumes the zonemd record is NOT calculated on the fly or
dynamically upon request.
6.3 last paragraph conflicts with 4.1 - e.g. if all you have is a
private hash, then you can't verify ZONEMD and .... well you get the
point. Basically, you have no signalling mechanism for when you might
be dependent on this record past NSEC/NSEC3. I don't know how to
resolve these two.
7.1 - add "This calculation does not take into the account any time
required to canonicalize a zone for processing".
Later, Mike
On 2/24/2020 6:06 PM, Wessels, Duane wrote:
All,
This version of the ZONEMD draft incorporates and addresses the feedback we
received from the working group last call. The list of changes is below.
Note there is one important change to the RDATA fields that we believe
addresses concerns about future proofing.
Previously there was a field named Digest Type, whose meaning incorporated both the hash
algorithm (e.g. SHA384) and a scheme for organizing the zone data as input to the hash
function (e.g. "simple"). These have been split into separate fields now (Hash
Algorithm and Scheme). The Parameter field has been dropped, but we feel its intended
use can still be accomplished with the Scheme field.
We hope this version addresses all the comments received. If there are any
omissions it was not intentional.
DW
From -03 to -04:
o Addressing WGLC feedback.
o Changed from "Digest Type + Paramter" to "Scheme + Hash
Algorithm". This should make it more obvious how ZONEMD can be
expanded in the future with new schemes and hash algorithms, while
sacrificing some of the flexibility that the Parameter was
intended to provide.
o Note: old RDATA fields: Serial, Digest Type, Parameter, Digest.
o Note: new RDATA fields: Serial, Scheme, Hash Algorithm, Digest.
o Add new IANA requirement for a Scheme registry.
o Rearranged some sections and separated scheme-specific aspects
from general aspects of digest calculation.
o When discussing multiple ZONEMD RRs, allow for Scheme, as well as
Hash Algorithm, transition.
o Added Performance Considerations section with some benchmarks.
o Further clarifications about non-apex ZONEMD RRs.
o Clarified inclusion rule for duplicate RRs.
o Removed or lowercased some inappropriately used RFC 2119 key
words.
o Clarified that all ZONEMD RRs, even for unsupported hash
algorithms, must be zeroized during digest calculation.
o Added Resilience and Fragility to security considerations.
o Updated examples since changes in this version result in different
hash values.
On Feb 24, 2020, at 2:53 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
Matt Weinberg
Warren Kumari
Wes Hardaker
Filename : draft-ietf-dnsop-dns-zone-digest-04.txt
Pages : 32
Date : 2020-02-24
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.
ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects
individual RRSets (DNS data with fine granularity), ZONEMD protects a
zone's data as a whole, whether consumed by authoritative name
servers, recursive name servers, or any other applications.
As specified at this time, ZONEMD is not designed for use in large,
dynamic zones due to the time and resources required for digest
calculation. The ZONEMD record described in this document is
designed so that new digest schemes may be developed in the future to
support large, dynamic zones.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-04
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
