Thanks for the latest update Duane. This current update does appear to all
the comments that were raised during the first WGLC.

We'll kick off a second WGLC in a separate email.

Tim



On Mon, Feb 24, 2020 at 6:08 PM Wessels, Duane <dwessels=
[email protected]> 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
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to