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

["Wessels, Duane" <[e-mail]>]

> On May 25, 2018, at 11:33 AM, 神明達哉 <[e-mail]> wrote:
> 
> At Wed, 23 May 2018 15:32:11 +0000,
> "Weinberg, Matt" <mweinberg=[e-mail]> 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.

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

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

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

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.


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

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.


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

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.

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

Yes, thank you for pointing that out!


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

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


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

This will be added.

DW