1.4.4 - "has not been modified." -> "has not been modified between
origination and retrieval."
2.2.2 - "MUST be implemented" -> "SHOULD be implemented. Failure to
implement this scheme without other standardized schemes being specified
may result in a receiver being unable to validate the zone. However, it
is possible to use ZONEMD with a private scheme, and for that reason the
requirement is set at "SHOULD"".
2.2.3 - "SHA384...that MUST be implemented." -> "SHA384 is the only
mandatory hash algorithm currently defined for the SIMPLE scheme, and
MUST be implemented if the SIMPLE scheme is implemented".
2.2.4 - SHA384 has a hash length of 48 bytes. 12 bytes seems to imply
some sort of left or right truncation. Show stopper! Explain how this
value was selected and how it interacts with the native length of the
chosen hash. Note: I have no trouble with truncated hashes here, but no
modern hash has less than 20 bytes so 12 seems to be a very strange
number absent a discussion of truncated hashes.
3.1 - "It is RECOMMENDED...SOA". Add "However, the TTL of the ZONEMD
record may be safely ignored during verification in all cases."
6.2 - *sigh* No. Basically, this allows a zone that is done ZONEMD to
push back on a parent zone that's doing key updates. (e.g. its not the
keys in the zone being ZONEMD you're concerned about in this paragraph,
but the keys in all of the parent zones). Use *EXACTLY* the same model
for ZONEMD that DNSSEC would use and with exactly the same implications
for verification. I'd delete this paragraph in its entirety.
Mike
On 9/21/2020 1:41 PM, internet-dra...@ietf.org 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-10.txt
Pages : 36
Date : 2020-09-21
Abstract:
This document describes a protocol and new DNS Resource Record that
provides 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 a 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 does not 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 herein, ZONEMD is impractical for large, dynamic zones
due to the time and resources required for digest calculation.
However, The ZONEMD record is extensible so that new digest schemes
may be added 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-10
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-10
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-10
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
