> On Mar 9, 2020, at 9:37 AM, Dick Franks <rwfra...@gmail.com> wrote: > > >>> [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. >>> >>> [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. >> >> para 5 is about filling out the RRset to have a ZONEMD placeholder record >> for each <Scheme,Hash Algorithm> pair. > > Indeed, that is what para 5 says. > > What I am calling into question is the necessity to bind each digest > to *all* of its siblings, > given that DNSSEC will be used to sign and protect the complete ZONEMD RRset.
It is not necessary. ZONEMD on an unsigned zone only protects from unintentional changes. Otherwise it is trivial to regenerate the digest. All that really matters is that we agree on the extent to which ZONEMD records should be included the digest calculation. > Binding each digest to its own placeholder should be sufficient, and I'm not necessarily opposed to that. It does mean that adding or deleting one ZONEMD record to/from the zone does not change any of the other ZONEMD digests that already exist. There may be advantages and/or disadvantages to that. > also removes the > apparent conflict with [3.1 para 2]: > Prior to calculation of the digest, ... a [singular] placeholder > ZONEMD record is added ... > > With this simplification, verification can be achieved using a single > ZONEMD, instead of > needing the entire RRset. > > Michael StJohns pointed out (Feb 25) that a verifier that does not > recognise a particular > ZONEMD Scheme and/or Hash Algorithm may be unable to create the > required placeholders, > and therefore unable to perform a verification using any > (Scheme,Algorithm) at all. I don't believe that to be the case. For the unknown schemes/algorithms the recipient simply replaces how ever many octets the received ZONEMD digest had with all zeros. > >>> [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. >>> >>> [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. >> >> Do you really want to update every AXFR implementation on the planet? > > Emphatically not; but neither does massaging the digest to gloss over an > erroneous duplication at the source seem like a sensible idea. > > Moreover, the independence of any particular transport mechanism is one > of the merits of this proposal. I think this is the difference between a "zone file" and a "zone". Due to the cited RFC, duplicated RRs are suprresed when a zone file becomes a zone. I don't consider it "massaging" the digest. I consider it calculating the digest over the proper zone data. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
