> On Mar 8, 2020, at 11:10 PM, Dick Franks <rwfra...@gmail.com> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
