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

[Michael StJohns <[e-mail]>]

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, [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-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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop