Hi, Replying on just one point:
On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns <m...@nthpermutation.com> wrote: > > ... > > 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. Well, previously the draft said that the length of the digest field must be larger than zero. Do you think that the previous text implied you could truncate to 1 byte? There is nothing in the draft about truncation. This is intended to prohibit any future hash algorithm specification (which could include a truncation operation) for ZOMEND that results in less than 12 bytes. 96 bits seems to be a common minimum length for disgests in the IETF although perhaps I have that impression due to the common case of SHA-1 truncated to 96 bits. However, I note that RFC 4635 on "HMAC SHA TSIG Algorithm Identifiers", issued in 2006, prohibits hashes less than 10 bytes or 80 bits. If the draft is going to specify a minimum length, I think it should be at least 96 bits. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > ... > > 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
