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

[Mukund Sivaraman <[e-mail]>]

On Fri, Jun 01, 2018 at 10:51:00AM +0000, Shane Kerr wrote:
> Wessels, Duane:
> > 
> >> 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.
> 
> As I mentioned, I have seen zones broken during transfer in production,
> and having a standard way to check for this seems reasonable.
> 
> >> - 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.
> 
> As I mentioned in my review of the first version of this document, I
> think that inserting digest records periodically throughout the zone
> could serve to allow incremental updates (as the recipient can cache
> unchanged values) and also allow a degree of parallelism.

Interesting. Merkle tree for the domain name space nodes would also be
suitable. It means that for a zone with a large number of labels at a
single domain tree level, all the individual hashes underneath would
have to be hashed, but it seems OK. e.g., with SHA-256:

[muks@jurassic ~]$ openssl speed sha256
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha256           67640.07k   146564.37k   254310.49k   313201.19k   337102.17k   339285.33k

Merkle tree would lend itself well to representation in current DNS tree
implementations, and they may be used for other DNS purposes in the
future too. ;)

Instead of use of plain SHA-1 and GOST in table 1, I'd like to see
SHA3-256. I'd also make SHA-384 as mandatory as for hashing this large
amount of data as SHA-512 is known to perform better than SHA-256 on
popular processors.

[muks@jurassic ~]$ openssl speed sha512
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha512           46730.69k   187840.56k   291941.29k   416484.51k   475806.75k   476692.21k

		Mukund