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

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 03 August 2018 03:25 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 C32CE130EEE for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 20:25:32 -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 Ox0ryuz7aJM0 for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 20:25:31 -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 A5D60130E10 for <dnsop@ietf.org>; Thu, 2 Aug 2018 20:25:31 -0700 (PDT)
Received: from [169.254.201.72] (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 w733PCZa001120 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Aug 2018 20:25:13 -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.201.72]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Date: Thu, 02 Aug 2018 20:25:29 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <293393AD-0DEF-47CA-9321-96A481D5F3D1@vpnc.org>
In-Reply-To: <alpine.LRH.2.21.1808022247150.6981@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> <54333970-0416-43BB-8E10-39A4617811AB@vpnc.org> <alpine.LRH.2.21.1808022247150.6981@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jwai7ft1Gi0UlcDgUpmzD0LNbpE>
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 03:25:33 -0000

On 2 Aug 2018, at 19:50, Paul Wouters wrote:

> On Thu, 2 Aug 2018, Paul Hoffman wrote:
>
>>>  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.
>
> Then don't cover signed RRsets with ZONEMD. Then this problem goes 
> away,
> and you force implementations to validate all records before putting
> them in the cache.

That only works for validating resolvers. ZONEMD also is useful for 
non-validating resolvers.

>> 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.
>
> That's not what people are going to do. They are going to grab the
> AXFR'ed data, check the checksum and throw it in the "validated" cache
> and they won't revalidate every root zone entry they are about to 
> serve.

A non-validating resolver doesn't have a validated cache.

--Paul Hoffman