Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 03 August 2018 00:35 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 756E6130E67 for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 17:35:42 -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 17IiPbqKe2TQ for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 17:35:40 -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 E9D28130E45 for <dnsop@ietf.org>; Thu, 2 Aug 2018 17:35:39 -0700 (PDT)
Received: from [10.32.60.134] (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 w730ZILZ086860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Aug 2018 17:35:20 -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 [10.32.60.134]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Date: Thu, 02 Aug 2018 17:35:34 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <54333970-0416-43BB-8E10-39A4617811AB@vpnc.org>
In-Reply-To: <alpine.LRH.2.21.1808021512160.1415@bofh.nohats.ca>
References: <CADyWQ+HizOJsE9EZ=VEvrbnnyPwaG_yBRg7fP5VvUNTdnidXZA@mail.gmail.com> <ybl4lgg6ztm.fsf@w7.hardakers.net> <m1fkRCk-0000GTC@stereo.hq.phicoh.net> <E10B9DE1-091E-45DF-9C23-380455113A21@kahlerlarson.org> <alpine.LRH.2.21.1808021512160.1415@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_0IwqpnWAqmLJk1hQIKgh4s0Y08>
Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
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, 03 Aug 2018 00:35:43 -0000

On 2 Aug 2018, at 12:14, Paul Wouters wrote:

> On Tue, 31 Jul 2018, Matt Larson wrote:
>
>> For all those reasons, I think a checksum in the zone file itself 
>> that can be verified with DNSSEC is the best option for this use 
>> case, and I like the ZONEMD solution.
>
> Note that the checksum in this case must be at least as
> cryptographically strong as the signature algorithm used
> in the individual RRSIGs/DNSKEYs.

Not true.

If the resolver is validating, the ZONEMD only adds assurance that the 
non-signed records are there. Thus, the hash algorithm for the zone is 
unrelated to the hash algorithms in the signatures.

If the resolver is not validating, the ZONEMD assures that all the 
records are there. The strength of that assurance is the same as the 
second pre-image strength of the hash. However, the resolver cannot say 
"oh, look, now I can start resolving with what I got in the zone 
transfer": it still needs to validate every RRSIG all the way to the 
root.

> This would have to be
> enforced by software/RFC to prevent a downgrade attack.

Given the above, what downgrade attack are you thinking of?

--Paul Hoffman