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

Florian Weimer <fw@deneb.enyo.de> Sat, 28 July 2018 15:47 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 E5332131055 for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 08:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 N_cVvPo3zyGG for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 08:47:41 -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 BCCC0130FAB for <dnsop@ietf.org>; Sat, 28 Jul 2018 08:47:41 -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 1fjRRS-0003KJ-6x; Sat, 28 Jul 2018 15:47:38 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from <fw@deneb.enyo.de>) id 1fjRRR-0000P9-Uo; Sat, 28 Jul 2018 17:47:37 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: John R Levine <johnl@taugh.com>
Cc: dnsop@ietf.org
References: <20180724143253.83ACC2002CE789@ary.qy> <87va8zh77f.fsf@mid.deneb.enyo.de> <alpine.OSX.2.21.1807281106550.71239@ary.qy>
Date: Sat, 28 Jul 2018 17:47:37 +0200
In-Reply-To: <alpine.OSX.2.21.1807281106550.71239@ary.qy> (John R. Levine's message of "28 Jul 2018 11:08:42 -0400")
Message-ID: <87k1pfgy5i.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LMLp9Wf0wfJsBXZsNVzqEXtrlHs>
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 15:47:51 -0000

* John R. Levine:

>>>> 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. ...
>
>> On the other hand, clients will likely have a pretty good idea for the
>> size of the zone, so they could transfer it twice: ...
>
> Now I'm really confused.  To avoid downloading the whole zone you download 
> it twice?
>
> Could you explain in simple terms why you can't download the zone, check 
> the digest and signature, and either use it or discard it?

A malicious server might never stop sending data, or claim that the
transfer is ridiculously large.  If the zone digest does not include
information about the amount of data, this can only be detected after
the server ended transmission, at which time the ZONEMD digest can be
compared.  But at this point, the client may already have filled its
storage with garbage data, unless the double transfer trick is used.