Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

["Wessels, Duane" <[e-mail]>]

> On Mar 8, 2020, at 11:10 PM, Dick Franks <[e-mail]> wrote:
> 
> draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a
> number of internal contradictions to be resolved.
> 
> 
> [1.2 para 1]
> 
>   ...  The procedures for digest calculation and DNSSEC
>   signing are similar (i.e., both require the same ordering of RRs) and
>   can be done in parallel.
> 
> There is no requirement for the RR collating sequence be the same as
> DNSSEC, otherwise it would be impossible for there to be more than one
> scheme.


Collation/scheme means more than just sorting.  It can also refer to how
the data is grouped or partitioned before digesting.  In the simple scheme
proposed here, all the zone data is sorted in a single partition.  A future
scheme could define a more sophisticated data structure that partitions
zone data by name, etc.  But the data within each partition would be sorted.

So you can have more than one scheme and still use DNSSEC sorting.  In my
opinion, DNSSEC sorting is sufficient, no matter the collating scheme.
The way to make ZONEMD perform well with incremental updates in a future
scheme is to define an efficient in-memory data structure and something
like a merkle tree.  The leafs of the merkle tree can still use DNSSEC
sorting, rather than needing to define some new sorting.

Having said that, I'm no opposed to change the text in 1.2.



> 
> [3.1 para 1]
> 
>   In preparation for calculating the zone digest, any existing ZONEMD
> +  and covering RRSIG
>   records at the zone apex are first deleted.

Happy to add this, although maybe unnecessary IMO because any time you delete
an RRset from a zone I'd expect the RRSIGs to also get deleted.


> 
> [3.1 para 1]
> 
>   Prior to calculation of the digest, and prior to signing with DNSSEC,
>   a placeholder ZONEMD record is added to the zone apex.
> 
> reword as follows:
> 
>   Prior to calculation of the digest, and prior to signing with DNSSEC,
>   exactly one placeholder ZONEMD record is added to the zone apex.
> 
> [3.1 para 5]
> 
> reword as follows:
> 
>   If multiple digests are to be published in the zone, e.g., during an
>   algorithm rollover, each digest calculation is performed independently
>   using the placeholder for the corresponding Scheme and Hash Algorithm.
> 
> [3.2]

I'll respond to this in your later followup message.


> 
> s/signature(s)/signature/
> 
> There can never be more than one.


Although perhaps not recommended or common, a zone can be signed with
multiple keys (ZSKs) so I'm not sure what you mean here?



> 
> [3.3] and [3.3.1]
> 
>    This specification adopts DNSSEC's canonical on-the-wire RR format
>    (without name compression) as specified in [RFC4034].
> 
>       RR(i) = owner | type | class | TTL | RDATA length | RDATA
> 
>       where "|" denotes concatenation.
> 
> The record collating sequence is scheme specific.

Yeah, good call.  I can move it to 3.3.


> 
> [3.4 bullet 3]
> 
>   o  Only one instance of duplicate RRs with equal owner, class, type
>      and RDATA SHALL be included ([RFC4034] Section 6.3).
> 
> This seems to detract from the idea of a general purpose comparison
> advertised in 1.3.5. If unexpected duplicate RRs were to be present in
> the original zone, the downstream copy should be expected to match,
> warts and all.
> 
> [3.5.1 para 5]
> 
> Needs to be incorporated into 3.3.

Not sure what you mean by that.


> 
> [3.6]
> 
> reword:
> 
>   Once a zone digest has been calculated, the published ZONEMD record
>   is finalised by inserting the digest into the placeholder ZONEMD.
>   Repeat for each digest if multiple digests are to be published.
> 
>   If the zone is signed with DNSSEC, the RRSIG record covering
>   the ZONEMD RRSet MUST then be added or updated.

Okay, thanks.


DW