Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

From: [email-masked]
Date: Thu, 05 Sep 2019 16:31:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Message Digest for DNS Zones
        Authors         : Duane Wessels
                          Piet Barber
                          Matt Weinberg
                          Warren Kumari
                          Wes Hardaker
	Filename        : draft-ietf-dnsop-dns-zone-digest-01.txt
	Pages           : 29
	Date            : 2019-09-05

Abstract:
   This document describes an experimental protocol and new DNS Resource
   Record that can be used to provide a message digest over DNS zone
   data.  The ZONEMD Resource Record conveys the message digest data in
   the zone itself.  When a zone publisher includes an ZONEMD record,
   recipients can verify the zone contents for accuracy and
   completeness.  This provides assurance that received zone data
   matches published data, regardless of how the zone data has been
   transmitted and received.

   ZONEMD is not designed to replace DNSSEC.  Whereas DNSSEC protects
   individual RRSets (DNS data with fine granularity), ZONEMD protects
   protects a zone's data as a whole, whether consumed by authoritative
   name servers, recursive name servers, or any other applications.

   As specified at this time, ZONEMD is not designed for use in large,
   dynamic zones due to the time and resources required for digest
   calculation.  The ZONEMD record described in this document includes
   fields reserved for future work to support large, dynamic zones.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 6 Sep 2019 00:01:55 +0000

Dear DNSOP,

The primary change between -00 and -01 is the simplification of the verification protocol
when multiple ZONEMD RRs are present, per the on-list discussions.

Additionally Shane Kerr kindly updated his implementation and confirmed that his and the
author's implementations produce and validate the same digests.

With this version the authors feel that it is ready for working group last call.

DW

> On Sep 5, 2019, at 4:31 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Shane Kerr <[email-masked]>
Date: Mon, 9 Sep 2019 10:03:53 +0200

Duane,

> With this version the authors feel that it is ready for working group last call.

Sorry for a late comment, but I decided to give this one thorough last 
read-through.

I'm a little concerned that the way the Reserved field is described may 
make adoption of later versions of ZONEMD difficult. The relevant text:

2.1.3.  The Reserved Field

    The Reserved field is an 8-bit unsigned integer, which is always set
    to zero.  This field is reserved for future work to support efficient
    incremental updates.
     .
     .
     .
4.  Verifying Zone Message Digest
     .
     .
     .
    7.   The Reserved field MUST be checked.  If the Reserved field value
         is not zero, verification MUST NOT be considered successful.

The question is, what can a zone producer do to support both this 
version of ZONEMD as well as a new version? Adding a non-zero Reserved 
ZONEMD value will break any implementation using this specification.

I think what would be ideal is for non-zero Reserved values to be ignored.

If we treat non-zero Reserved the same as unknown algorithms (that is, 
using placeholders) will that be okay? It may complicate generating 
compatible ZONEMD in future ZONEMD implementations. With the envisioned 
incremental version I think it will be fine; if you want both a 
full-zone and incremental ZONEMD then it will indeed be complicated, but 
I think probably few zones will need that. I have no idea whether using 
the placeholder technique will work for more weird and wonderful later 
versions.

I suppose it is okay to reject the use case and not worry about 
compatibility, since we expect the incremental version to be used mostly 
for large zones where the current ZONEMD simply won't work... 🤔

Cheers,

--
Shane

---

From: George Michaelson <[email-masked]>
Date: Mon, 9 Sep 2019 16:13:53 +0700

This is a not uncommon problem in 'make this protocol work in future' spec.
It could say "for version ZERO of this protocol" and then say "future
versions of this protocol should stipulate what other values mean, and how
this affects handling of all-zeros state, and other states"

Saying "must not validate" baldly basically says "will always be zero" to
me -Which I think is what you're saying!

_G

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 10 Sep 2019 23:18:08 +0000

Thanks Shane & George, I agree this needs some clarification.

Something thats probably missing from the document is that in any future revision of ZONEMD we expect backwards compatibility.  For this version, it is expected that Reserved is set to zero.  In a future version, if the formerly reserved field can have non-zero values, then a value of zero there should produce the exact same hashes as it does in this version.

I gave a presentation at DNS-OARC last year with some experiments in making large dynamic zones more efficient.  There I used the reserved field to encode the depth of a Merkle tree.  A depth of zero corresponds to effectively no tree which is the same as described in the current version.

Recently Mukund posted here a proposal of his for how to store zone data in memory in a ZONEMD-compatible way.  While slightly different than my idea, I believe his also could be implemented in a way such that the reserved field encodes what the consumer needs to know about how the data should be stored and the hash computed for interoperation.

If we agree that a value of zero in this field produces the same hash value in this version and future versions of ZONEMD, then shouldn't we say that it is an error to have non-zero values at this time?  If we say it is acceptable to ignore non-zero values at this time, then it would lead to incompatible hash values in the future version.

DW

> On Sep 9, 2019, at 2:13 AM, George Michaelson <[email-masked]> wrote:
> 
> This is a not uncommon problem in 'make this protocol work in future' spec. It could say "for version ZERO of this protocol" and then say "future versions of this protocol should stipulate what other values mean, and how this affects handling of all-zeros state, and other states"
> 
> Saying "must not validate" baldly basically says "will always be zero" to me -Which I think is what you're saying!
> 
> _G
>

---

From: Richard Gibson <[email-masked]>
Date: Wed, 11 Sep 2019 01:10:46 -0400

The following excerpts allow for and even encourage software written 
against this document in its present form to behave in ways that will 
hinder adoption of future changes, and should probably be altered in 
order to foster the desired compatibility.

Section 2 requires "Each ZONEMD RR MUST specify a unique Digest Type", 
which means that a name server written against this document would be 
justified in rejecting a zone containing both a SHA384 ZONEMD RR with 
Reserved=0 and a SHA384 ZONEMD RR with Reserved!=0.

Section 2.2 declares that "The [presentation format] Reserved field MUST 
be represented as an unsigned decimal integer set to zero", which means 
that software written against this document would be justified in 
rejecting a master file containing a ZONEMD RR with nonzero Reserved.

In Section 3.2 ZONEMD placeholder records, "The Digest field MUST be set 
to all zeroes and of length appropriate for the chosen digest 
algorithm", which may poorly accommodate variable-length digests and 
result in interoperability issues.

Section 1 anticipates "a name server can verify the zone data it was 
given and refuse to serve a zone which fails verification" but Section 4 
declares that digest verification MUST NOT be considered successful if 
"If the zone contains more than one apex ZONEMD RR" or "If the Reserved 
field value is not zero", which means that software written against this 
document would be justified in rejecting a zone containing a ZONEMD 
described by either of those conditions. This is the crux of the 
compatibility concerns, and I think it would be best corrected by 
restricting step 4 failures to zones containing "more than one apex 
ZONEMD RR /with Reserved field equal to zero and the same Digest Type/" 
and updating later steps such that they apply for each ZONEMD RR and 
failures mean "digest verification MUST NOT be considered successful 
/for that RR/".

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 12 Sep 2019 18:06:44 +0000

Hi Richard, thanks for the review.

This and the earlier messages makes me think that perhaps it would be better to bump the digest type (while possibly using the same hash algorithm) in a future revision, when the reserved field takes on meaning.

> On Sep 10, 2019, at 10:10 PM, Richard Gibson <[email-masked]> wrote:
> 
> The following excerpts allow for and even encourage software written against this document in its present form to behave in ways that will hinder adoption of future changes, and should probably be altered in order to foster the desired compatibility.
> 
> Section 2 requires "Each ZONEMD RR MUST specify a unique Digest Type", which means that a name server written against this document would be justified in rejecting a zone containing both a SHA384 ZONEMD RR with Reserved=0 and a SHA384 ZONEMD RR with Reserved!=0.
> 
> Section 2.2 declares that "The [presentation format] Reserved field MUST be represented as an unsigned decimal integer set to zero", which means that software written against this document would be justified in rejecting a master file containing a ZONEMD RR with nonzero Reserved.
> 
> In Section 3.2 ZONEMD placeholder records, "The Digest field MUST be set to all zeroes and of length appropriate for the chosen digest algorithm", which may poorly accommodate variable-length digests and result in interoperability issues.

Are there really variable length digests whose length would not be known at the time of placeholder creation?  If so then it would be better to just omit the digest field from the digest calculation.

> 
> Section 1 anticipates "a name server can verify the zone data it was given and refuse to serve a zone which fails verification" but Section 4 declares that digest verification MUST NOT be considered successful if "If the zone contains more than one apex ZONEMD RR" or "If the Reserved field value is not zero", which means that software written against this document would be justified in rejecting a zone containing a ZONEMD described by either of those conditions. This is the crux of the compatibility concerns, and I think it would be best corrected by restricting step 4 failures to zones containing "more than one apex ZONEMD RR with Reserved field equal to zero and the same Digest Type" and updating later steps such that they apply for each ZONEMD RR and failures mean "digest verification MUST NOT be considered successful for that RR".

Yes, this is a good catch.  That was sort of leftover from when there was only going to be one ZONEMD.  It needs to be updated for multiple digests.

DW

>>> On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr 
>>> <[email-masked]>
>>>  wrote:
>>> Duane,
>>>