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

Mark Andrews <marka@isc.org> Fri, 27 July 2018 01:32 UTC

Return-Path: <marka@isc.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 528BC130E08 for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 18:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jynU3PBK19o0 for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 18:32:47 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 83ABC130E04 for <dnsop@ietf.org>; Thu, 26 Jul 2018 18:32:47 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 345643AB042; Fri, 27 Jul 2018 01:32:47 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DB31B160038; Fri, 27 Jul 2018 01:32:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A00C6160075; Fri, 27 Jul 2018 01:32:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uJHABolMWaYe; Fri, 27 Jul 2018 01:32:43 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8DED1160038; Fri, 27 Jul 2018 01:32:42 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <FEB616DB-F4AE-4E2B-A9A5-DD01E5FB4354@vpnc.org>
Date: Fri, 27 Jul 2018 11:32:40 +1000
Cc: Ondrej Sury <ondrej@isc.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F80C4A53-D2C0-4061-BF98-1FE1797FA574@isc.org>
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <6FFED142-0752-40FD-AF5C-7E9D6617DC03@isc.org> <056430ED-F87E-4170-B2D0-0EA3F57D9C60@verisign.com> <3B9A8C03-3095-46EE-A5FF-0EFC0D9FD3ED@isc.org> <872BB5B5-A685-4B65-BA22-C9B352A58BD9@vpnc.org> <5ECF7D77-045A-4F7F-9126-289F62F97FE5@isc.org> <FEB616DB-F4AE-4E2B-A9A5-DD01E5FB4354@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bwFSslCDMqHow5gZA4ZEz6oUUJs>
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: Fri, 27 Jul 2018 01:32:49 -0000


> On 27 Jul 2018, at 10:37 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 26 Jul 2018, at 10:25, Ondřej Surý wrote:
> 
>>> If the ZONEMD record is signed, the only person who can mount a collision attack is the zone owner themselves. If the ZONEMD record is unsigned, an attacker can just remove it.
>> 
>> I believe, that’s not true.  The ZONEMD can stay intact while the attacker would modify the unsigned parts of the zone to create a same checksum, but different contents?  He might be targeting just this particular zone and it’s delegation, so everything else is throw-away junk that can be modified.
>> 
>>> What is the attack you are envisioning?
> 
> You didn't answer the last question. It sounds like you want it as a signature over the entire zone. If so, then I fully agree that using hash algorithms that have known collision attacks is a very bad idea. But I also think that using ZONEMD as a strong signature is a bad idea: that's what signing algorithms are for.

ZONEMD and XHASH can both be modelled as a cryptographic hash (NSEC3) or cryptographic hash + signature (RRSIG).  The later will take less space in the zone but more work to update when the signature expires.  Either model will prevent record changes.
 
> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org