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

[Dick Franks <[e-mail]>]

Response in line

On Mon, 9 Mar 2020 at 07:20, Mark Andrews <[e-mail]> wrote:

>8

> > [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.
>
> I see no proof for this claim.

Self evident:  If a "Scheme" defines its own collating sequence, then
it is certainly
possible to define another Scheme with a different collating sequence.
The collating sequence therefore can not be constrained to be the same
as DNSSEC.
Also, the eventual goal is to incorporate some as yet unspecified
incremental scheme,
which is a whole new can of worms and unlikely to fit the DNSSEC model.

> > [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.

Binding each digest to its own placeholder should be sufficient, and
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.

> > [3.2]
> >
> > s/signature(s)/signature/
> >
> > There can never be more than one.
>
> Actually there can be multiple RRSIG for ZONEMD so plural is correct.

There is only ONE RRset at the apex, therefore only ONE covering RRSIG
which needs to be regenerated.

> > [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.

> > [3.5.1 para 5]
> >
> > Needs to be incorporated into 3.3.
> >
> > [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.
> >
_____________________________________________