Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

[Barry Leiba <[e-mail]>]

I just put it into IESG Evaluation a couple of hours ago.  The recent
changes were to address the SecDir review, which you can see here:
https://mailarchive.ietf.org/arch/msg/secdir/RYS_YRmcHvwEauT-6UhvtqSJ9-8/

Barry

On Mon, Sep 21, 2020 at 3:06 PM Michael StJohns <[e-mail]> wrote:
>
> Adding IESG - I didn't realize it was in IESG evaluation.
>
> I'm not sure why this version was posted as there is nothing on the
> datatracker that indicates there were IESG issues to be resolved.  There
> are several changes that were non-editorial that really shouldn't have
> been included without WG review.  2.2.4 is the one that I would have
> problems with the most.
>
> Mike
>
>
> On 9/21/2020 2:26 PM, Michael StJohns wrote:
> > 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, [e-mail] 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >
> >
>