Subject: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

From: "Weinberg, Matt" <[email-masked]>
Date: Wed, 23 May 2018 15:32:11 +0000

Greetings dnsop,

We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note, this -01 version includes the following changes:

	• Warren Kumari and Wes Hardaker have been added as coauthors.
	• Several points of clarification in wording and descriptions.
	• Removed the requirement to sort by RR CLASS.
	• Added a Change Log section.

Warren and Wes had started on a very similar but unpublished draft, which we should've remembered.  Thanks to them for agreeing to join this document as coauthors.
We plan to ask for time on the dnsop agenda in Montreal.  Your feedback is welcome and appreciated.    

Thanks.

----
    
    A new version of I-D, draft-wessels-dns-zone-digest-01.txt
    has been successfully submitted by Matt Weinberg and posted to the
    IETF repository.
    
    Name:		draft-wessels-dns-zone-digest
    Revision:	01
    Title:		Message Digest for DNS Zones
    Document date:	2018-05-17
    Group:		Individual Submission
    Pages:		13
    URL:            https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
    Htmlized:       https://tools.ietf.org/html/draft-wessels-dns-zone-digest-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-01
    
    Abstract:
       This document describes a protocol and DNS Resource Record used to
       provide a message digest over DNS zone data.  In particular, it
       describes how to compute, sign, represent, and use the message digest
       to verify the contents of a zone for accuracy and completeness.  The
       ZONEMD Resource Record type is introduced for conveying the message
       digest data.

    
    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.
    
    The IETF Secretariat

---

From: 神明達哉 <[email-masked]>
Date: Fri, 25 May 2018 11:33:27 -0700

At Wed, 23 May 2018 15:32:11 +0000,
"Weinberg, Matt" <mweinberg=[email-masked]> wrote:

> We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note,
this -01 version includes the following changes:
[...]
> We plan to ask for time on the dnsop agenda in Montreal.  Your feedback
is welcome and appreciated.

I've read the draft.  I have a few high level comments and specific
feedback on the draft content:

- It was not really clear exactly what kind of problem this digest
   tries to solve, especially given that the primarily intended usage
   is for the root zone, which is DNSSEC-signed with NSEC.  In that
   primary case we should be able to check the integrity of the
   entire zone with DNSSEC (including a complete list of authoritative
   names and RR types for each name), right?  One thing I can think of
   is integrity including glue records, but it's not clear from the
   draft whether the digest includes these records (see also below),
   and even if so, it seems to be a relatively minor addition.  So I'm
   wondering I'm missing something very trivial.  Even so, it would be
   nice to clarify the intended advantage(s) over DNSSEC-based
   integrity check for the root zone case.

- This digest can't be incrementally updated, that is, you'll need to
   calculate the digest over the entire zone even if just a single
   record is modified (am I correct?).  That's probably an inevitable
   cost for the motivation of providing cryptographically strong
   integrity check, but that's a pity for me.  One case I know of where
   things like "zone digest" is wanted is to ensure consistency for a
   very large zone between primary and secondary servers that are
   synchronized using IXFR.  In principle they must be consistent, but
   operators may want to have a lightweight (albeit not
   cryptographically strong) way to confirm no unexpected events (such
   as an implementation bug) quietly broke the consistency.  Perhaps
   such usage is just outside the scope of this proposal, but I first
   expected I could use it for this kind of purpose it was a bit
   disappointing and I wanted to mention it.

Specific comments:

- Section 4.1

    This specification adopts DNSSEC's canonical ordering for names
    (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an

   This means upper case letters in owner names are converted to lower
   case ones.  It could be considered a feature, but I guess some
   operators might want to check integrity including letter case of
   names.  For example, recent versions of ISC BIND 9 tries quite hard
   to preserve the letter case of owner names per RRset basis, which I
   think suggests operator needs for preserving the case as much as
   possible.

- Section 4.1.2

    [...]  However, according to the
    requirement to sort RRsets with the same owner name by type, the SOA
    RR (type value 2) might not be first in the digest calculation.  If
    the zone has an A RR (type value 1) at the apex, it MUST be processed
    before the SOA RR.

   SOA's type value is 6, not 2.  This also means you might rather want
   to use NS (type value 2) instead of A, since you don't need to add
   'if', as long as the zone is reasonably valid to have both SOA and
   NS.

- Section 4.4

    The zone digest is calculated by concatenating the canonical on-the-
    wire form of RRs in the zone, in the order described above, subject
    to the inclusion/exclusion rules described below, and then applying
    the digest algorithm:

   I wonder whether glue records are included in these RRs.  Either
   way, it would be better to clarify the point.

- Section 4.5

    If the zone is signed with DNSSEC, the appropriate RRSIG records
    covering the ZONEMD record MUST then be added.  Because the ZONEMD
    placeholder was added prior to signing, the zone will already have
    the appropriate denial-of-existence (NSEC, NSEC3) records.

   I would suggest clarifying that this 'resigning' MUST NOT change the
   SOA serial (it MUST NOT, right?).  It may depend on specific
   implementation or operational practices, but I know of
   implementations that increase the serial for every such incremental
   resigning.  So it would be prudent to explicitly note that this case
   is an exception for such practices.

--
JINMEI, Tatuya

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 31 May 2018 18:18:16 +0000

> On May 25, 2018, at 11:33 AM, 神明達哉 <[email-masked]> wrote:
> 
>   is for the root zone, which is DNSSEC-signed with NSEC.

Thanks you for the feedback.  We will write a clearer problem statement
in the introduction for the next version.

> In that
>   and even if so, it seems to be a relatively minor addition.

Yes, we intend to include glue records in the digest.  The proposal is to
have a digest over the zone as a whole.  So that is ALL records in the
zone.

>  So I'm

We can clarify that in the next version.  Essentially we feel the digest
technique provides two advantages over a straight DNSSEC-based integrity
check: (1) it covers unsigned data (glue, delegations, NSEC3 opt-out spans),
and (2) just one signature to validate.

>   disappointing and I wanted to mention it.

Incremental updates could be supported if the working group feels it is
important.  We have a working proof-of-concept implementation of this that
hashes individual RRsets and then XORs them into a final message digest
(thanks to Roy Arends for the suggestion).

However, this complicates the implementation.  It almost certainly requires
more CPU processing but probably not to an extent that matters significantly.
We could do some simple benchmarks.

If there is desire to follow this path, then we should discuss whether or
not to keep having the zone digest algorithms exactly match the DS digest
algorithms.  For example, digest alg 2 could mean "SHA256 over the zone
as a whole" while digest alg 3 could mean "SHA-256 digest and XOR individual
RRsets" to support incremental updates.

>   think suggests operator needs for preserving the case as much as

We do not propose that owner names be permanently converted.  DNSSEC has this
same characteristic, does it not?  The validator canonicalizes the owner names
upon validation, but does not cache them canonicalized.

>   'if', as long as the zone is reasonably valid to have both SOA and

Yes, thank you for pointing that out!

>   way, it would be better to clarify the point.

If we say "calculated by concatenating ... all RRs in the zone" is that sufficient?

>   is an exception for such practices.

This will be added.

DW