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

Tony Finch <dot@dotat.at> Wed, 04 April 2018 13:15 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559DB127333 for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 06:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d96quc5PZrIk for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 06:15:31 -0700 (PDT)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73BC1204DA for <dnsop@ietf.org>; Wed, 4 Apr 2018 06:15:31 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:54406) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f3iG8-0008md-9a (Exim 4.89_2) (return-path <dot@dotat.at>); Wed, 04 Apr 2018 14:15:29 +0100
Date: Wed, 04 Apr 2018 14:15:28 +0100
From: Tony Finch <dot@dotat.at>
To: Shane Kerr <shane@time-travellers.org>
cc: dnsop@ietf.org
In-Reply-To: <4cd3191a-e53c-87ad-1a6d-cbeee414b62f@time-travellers.org>
Message-ID: <alpine.DEB.2.11.1804041354230.20829@grey.csi.cam.ac.uk>
References: <152277670738.22791.3511791082557717517.idtracker@ietfa.amsl.com> <88E182D8-64C4-4FFE-961C-AA3571F8A86B@verisign.com> <4cd3191a-e53c-87ad-1a6d-cbeee414b62f@time-travellers.org>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/X5d10nPsPRw0jcrG-a-bp-aupZM>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2018 13:15:36 -0000

Shane Kerr <shane@time-travellers.org> wrote:
> Wessels, Duane:
> >
> > This draft proposes a technique and new RR type for calculating and
> > verifying a message digest over the contents of a zone file.  Using
> > this technique, the recipient of a zone containing the new RR type can
> > verify it for completeness and correctness, especially so when the
> > zone is signed.  We welcome your feedback on this document.
>
> I think this is a great idea. Certainly one of the things that we were
> missing in the Yeti project was a way to confirm that the contents of
> the root zone transfered from any particular master were actually the
> correct version, so this fills a real need.

Yep, interesting.

A couple of thoughts/questions:

The sorting algorithm specifies CLASS as part of the sort key. This is
fine, but slightly redundant since all records in a zone have the same
class :-)

Regarding efficiency, I wonder if there would be much win from giving it a
bit more of a tree structure, e.g.

; similar ordering to RRSIG calculation
digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
                                      RR(i,1) | ... | RR(i,ri) )

digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )

digest = digest_algorithm( digest_owner(1) | ... )

So when updating a zone, you can just recalculate the digests for the
affected owner names, then re-digest the string of digests. This should be
faster for signed zones, but it might not be a win for unsigned zones (a
SHA256 is about the same size as an A record).

(Following the hierarcial structure of owner names is probably not worth
it given the flatness of most zones.)

> Is it worth exploring the possibility of including multiple ZONEMD in a
> zone at different names, which digest the part of the zone up to that
> point?

Also a good idea :-) It probably needs to look a bit more like NSEC to
make it explicit which owners are covered.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Plymouth, Biscay: West 5 to 7, occasionally gale 8 at first, backing south 3
or 4, occasionally 5 later. Rough or very rough. Showers, then fair. Good.