Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt
Shane Kerr <shane@time-travellers.org> Wed, 04 April 2018 11:02 UTC
Return-Path: <shane@time-travellers.org>
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 18B32127137 for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 04:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 uoGVE2QSbi6M for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 04:02:02 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5790D1270B4 for <dnsop@ietf.org>; Wed, 4 Apr 2018 04:02:02 -0700 (PDT)
Received: from [78.109.23.1] (helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1f3gBp-0008BQ-UM for dnsop@ietf.org; Wed, 04 Apr 2018 11:02:54 +0000
To: dnsop@ietf.org
References: <152277670738.22791.3511791082557717517.idtracker@ietfa.amsl.com> <88E182D8-64C4-4FFE-961C-AA3571F8A86B@verisign.com>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <4cd3191a-e53c-87ad-1a6d-cbeee414b62f@time-travellers.org>
Date: Wed, 04 Apr 2018 11:01:00 +0000
MIME-Version: 1.0
In-Reply-To: <88E182D8-64C4-4FFE-961C-AA3571F8A86B@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SWAInODGvffTiM8UZJrNndHRNUc>
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 11:02:05 -0000
Duane, 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. One issue is that the algorithm proposed requires that the recipient who is generating a digest has to store basically the entire zone before beginning the digest calculation, since it has no way to know if the zone will be delivered in any kind of canonical order. It might be nice to have some way to signal that. I'm not sure exactly how, and possibly that belongs in a separate document (maybe we can tack it onto MIXFR?), but it seems like a potential problem as it adds extra work (possibly re-reading the entire zone an extra time along with the associated I/O, memory consumption, and unneeded latency due to checking). As for specific questions in the draft: * I think that it should be allowed for unsigned zones. If nothing else, it provides the equivalent of checksum to help prevent truncations or not properly updated records (missing deletions or additions). * I don't see much benefit in multiple ZONEMD. We generally expect masters & slaves to co-operate, so they should be able to find software that has an algorithm that both sides support. * I think the serial in ZONEMD is helpful. Doesn't it also help prevent replay attacks? * I would rather not special-case ZONEMD regarding responding. Even though it is bigger than most RDATA, large responses seem like a general problem. OTOH, I won't object too loudly if someone feels very strongly that this should be an option. A final possible concern is that generating a digest on a large zone might be computationally quite expensive. Indeed it could be used as an attack vector on a hosting provider by using small IXFR to cause large zone digests to be repeatedly calculated. 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? So something like: a.example.com ... . . . n.example.com ... n.example.com ... ZONEMD ... ; covers a-n . . . z.example.com ... example.com ... ZONEMD ... ; covers o-z (Sorry this needs to be more carefully thought through, but that's the basic idea.) Cheers, -- Shane
- [DNSOP] Fwd: New Version Notification for draft-w… Wessels, Duane
- Re: [DNSOP] Fwd: New Version Notification for dra… Shane Kerr
- Re: [DNSOP] Fwd: New Version Notification for dra… Tony Finch
- Re: [DNSOP] Fwd: New Version Notification for dra… Wessels, Duane
- Re: [DNSOP] Fwd: New Version Notification for dra… Wessels, Duane
- Re: [DNSOP] Fwd: New Version Notification for dra… Shane Kerr
- Re: [DNSOP] Fwd: New Version Notification for dra… 神明達哉