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

Paul Wouters <paul@nohats.ca> Fri, 03 August 2018 02:50 UTC

Return-Path: <paul@nohats.ca>
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 3B105130E0C for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 19:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 HsrfaSyEpfdA for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 19:50:50 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3CF99130DEE for <dnsop@ietf.org>; Thu, 2 Aug 2018 19:50:50 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41hWkY2HNvz39n for <dnsop@ietf.org>; Fri, 3 Aug 2018 04:50:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1533264645; bh=1Jqo8si2v7M0WFJae7T0B7liNiCF5km+YqgXFjEtv+A=; h=Date:From:To:Subject:In-Reply-To:References; b=Nv/34ptksoPepj6mA4NH/1aBDpkYX7mvwVlFyQHCWzCMQ2bSI2HdA9SdNswzATu6a YKEKHTQyOCEGS84JjqVKQccAJ9mm4GGLxW6l00lzCjGr3EzG+BuhMu4DBIFKYMISbi vaXl3/l9PY1cSNTv1qManT+hd8JZmUdWH4ESOHCU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id hzAyjJKjnW7T for <dnsop@ietf.org>; Fri, 3 Aug 2018 04:50:43 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Fri, 3 Aug 2018 04:50:42 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8B2F51FEE2; Thu, 2 Aug 2018 22:50:40 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8B2F51FEE2
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 58AC540D37FB for <dnsop@ietf.org>; Thu, 2 Aug 2018 22:50:40 -0400 (EDT)
Date: Thu, 02 Aug 2018 22:50:40 -0400
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <54333970-0416-43BB-8E10-39A4617811AB@vpnc.org>
Message-ID: <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>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n90ft-ktaAxv1T_1rzf98XPy-YQ>
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 02:50:52 -0000

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.

> 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.

Paul