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

From: Dick Franks <[email-masked]>
Date: Mon, 9 Mar 2020 06:10:57 +0000

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.

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

[3.2]

s/signature(s)/signature/

There can never be more than one.

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

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

Dick Franks
________________________

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Mar 2020 18:20:14 +1100

> On 9 Mar 2020, at 17:10, Dick Franks <[email-masked]> wrote:
> 

I see no proof for this claim.

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

> There can never be more than one.

Actually there can be multiple RRSIG for ZONEMD so plural is correct.

> the original zone, the downstream copy should be expected to match,

Do you really want to update every AXFR implementation on the planet?

RFC 5936

			Each RR SHOULD be transmitted only once, and
   AXFR clients MUST ignore any duplicate RRs received. 

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Dick Franks <[email-masked]>
Date: Mon, 9 Mar 2020 16:37:47 +0000

Response in line

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

>8

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

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

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

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

> >   the ZONEMD RRSet MUST then be added or updated.
_____________________________________________

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 9 Mar 2020 20:23:55 +0000

> On Mar 8, 2020, at 11:10 PM, Dick Franks <[email-masked]> wrote:
> 

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.

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

>   using the placeholder for the corresponding Scheme and Hash Algorithm.

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

> 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?

> The record collating sequence is scheme specific.

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

> Needs to be incorporated into 3.3.

Not sure what you mean by that.

>   the ZONEMD RRSet MUST then be added or updated.

Okay, thanks.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 9 Mar 2020 20:46:44 +0000

> On Mar 9, 2020, at 9:37 AM, Dick Franks <[email-masked]> wrote:
> 
> 
>>> [3.1 para 1]
>>> 

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.

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

> 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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 9 Mar 2020 17:24:05 -0400

> the recipient simply replaces how ever many octets the received ZONEMD digest

As of right now, I don't believe the current format is future proofed.

Current encoding:

0x01 - simple
0x01 - SHA384
48 bytes of digest.

0x01 - simple
0x02 - SHA512
64 bytes of digest.

0x02 - Complex
0x00 - Ignored - mainly because I'm forced to have it here because of 
the SIMPLE scheme - it doesn't specify a digest type.
[Opaque values that describe the complex scheme - e.g. btree 
description, partial hashes, selection matrix of RRs I actually care 
about etc]
[More opaque values that are the various digest(s)]

These are OPAQUE from a receiver that only understands SIMPLE.

For the latter scheme, I want to include the first part of the opaque 
values in the various hash calculations.   But the SIMPLE scheme will 
set them to zero for its own calculations?   And I have to do special 
things for scheme 1 to do my calculations.  AND I have to know that 
digest 0x02 requires 64 bytes of zero for the calculation even if I'm 
only able to verify SHA384 digests.  Any error in the formation of the 
digest 0x02 digest field or scheme 0x02 data field means that the 0x01 
digest won't verify.  Ditto for any formation for the scheme 2 complex 
digest relative to the Scheme 1 digests.  This makes all digests 
interdependent which I believe was not desired.

I see no benefit to including the ZONEMD RR in any digest calculation 
with our without placeholdering it.

Just omit any ZONEMD RR from the calculation and be done with it.  Make 
ALL ZONEMD RRs independent from each other.