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

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 30 July 2018 22:44 UTC

Return-Path: <paul.hoffman@vpnc.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 707441311AC for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 15:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ydHzMfjFeDEX for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 15:44:16 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 F189D1311C0 for <dnsop@ietf.org>; Mon, 30 Jul 2018 15:44:15 -0700 (PDT)
Received: from [169.254.42.118] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w6UMhuq0008440 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jul 2018 15:43:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.42.118]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: dnsop@ietf.org
Date: Mon, 30 Jul 2018 15:44:11 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <4D279E9E-965C-4176-BCEB-EFE6D140F443@vpnc.org>
In-Reply-To: <84FAA6E0-DF87-4C3B-B033-2830AD6C7675@verisign.com>
References: <20180724143253.83ACC2002CE789@ary.qy> <84FAA6E0-DF87-4C3B-B033-2830AD6C7675@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jfuPLbPhQi0RE8534CAc4tc3IwY>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 30 Jul 2018 22:44:24 -0000

On 30 Jul 2018, at 14:44, Wessels, Duane wrote:

> While I wouldn't necessarily be opposed to having an RR count field of 
> some kind if there is good reason to have it, my preference would be 
> to omit it and keep the record simpler.

I am still mystified about the scenario in which a malicious zone 
operator creates two zone files with the same ZONEMD hash, one with the 
right set of addresses for unsigned child zones, and a different one 
with one of more of those child zones with wrong addresses plus enough 
other kruft to make the colliding hashes match. In what world is that 
attack more likely than just not using ZONEMD?

And, even if it is possible to imagine that, requiring a hash function 
that has no collision attacks (like SHA-256) would suffice.

Adding a RR count field would only make the malicious zone owner's 
attack harder, and would complicate the field. But I still can't picture 
malicious zone operators who would voluntarily use ZONEMD.

--Paul Hoffman