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

Florian Weimer <fw@deneb.enyo.de> Sat, 28 July 2018 12:32 UTC

Return-Path: <fw@deneb.enyo.de>
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 1FC1E130F4A for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 05:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 z23pCn9ectns for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 05:32:09 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (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 D2F82130F44 for <dnsop@ietf.org>; Sat, 28 Jul 2018 05:32:08 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1fjOOD-0007vr-06; Sat, 28 Jul 2018 12:32:05 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from <fw@deneb.enyo.de>) id 1fjOOC-0006Ot-PB; Sat, 28 Jul 2018 14:32:04 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: John Levine <johnl@taugh.com>
Cc: dnsop@ietf.org
References: <20180724143253.83ACC2002CE789@ary.qy>
Date: Sat, 28 Jul 2018 14:32:04 +0200
In-Reply-To: <20180724143253.83ACC2002CE789@ary.qy> (John Levine's message of "24 Jul 2018 10:32:53 -0400")
Message-ID: <87va8zh77f.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-8K1iC4y1U9APtW01qFDJZEzI9E>
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: Sat, 28 Jul 2018 12:32:11 -0000

* John Levine:

> In article <87h8kp7sqf.fsf@mid.deneb.enyo.de> you write:
>>The ZONEMD record should contain a size indicator for the zone,
>>something that allows a receiver to stop downloading if it is clear
>>that the served zone is too large.  Otherwise, the receiver has to
>>download the entire zone before it can determine that the hash does
>>not match.
>
> I don't understand why this is a problem that needs solving.  Are we
> really attacked by broken zone files with large amounts of added junk,
> that are so large that reading them through before discarding them is
> a practical performance problem?

It's a practical problem if you want to update the zone from a
completely untrusted source.  I assumed that was in scope for ZONEMD.

On the other hand, clients will likely have a pretty good idea for the
size of the zone, so they could transfer it twice: Once for computing
the authenticated size, in hashing-only mode, once they realize that
the size of the new version exceeds the current version by 15% (or
so).  And after the authenticated size is known, they download the new
version for real.  This complexity could be avoided if the server
simply told how many bytes have been hashed in the digest.