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

Florian Weimer <fw@deneb.enyo.de> Sun, 29 July 2018 21:07 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 B92B0130E40 for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 14:07:21 -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 g6ksv6rTrdee for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 14:07:19 -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 6FF64130E06 for <dnsop@ietf.org>; Sun, 29 Jul 2018 14:07:19 -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 1fjsuK-0007RJ-Kj; Sun, 29 Jul 2018 21:07:16 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from <fw@deneb.enyo.de>) id 1fjsuK-0004gX-B3; Sun, 29 Jul 2018 23:07:16 +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> <87k1pfgy5i.fsf@mid.deneb.enyo.de> <alpine.OSX.2.21.1807281207520.72264@ary.qy>
Date: Sun, 29 Jul 2018 23:07:16 +0200
In-Reply-To: <alpine.OSX.2.21.1807281207520.72264@ary.qy> (John R. Levine's message of "28 Jul 2018 12:13:13 -0400")
Message-ID: <87wotdu4xn.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jHKfy4QBNQX3o17vo-Lplxa8vRM>
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: Sun, 29 Jul 2018 21:07:22 -0000

* John R. Levine:

> On Sat, 28 Jul 2018, Florian Weimer wrote:
>> 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.
>
> I realize that hypothetically a malicious server could send you a large 
> file of garbage.  But that can happen any time you downlaod a file from 
> anywhere.  It doesn't strike me as something that needs special hackery 
> for this rather specific case.

A lot of other updaters use HTTPS, which does not have this issue if
the terminating party is also the source of the data.  Those that do
not use other mechanisms.  There is quite a bit of previous work in
this area (see <https://theupdateframework.github.io/> for specific
take on this subject), and the current ZONEMD draft does not
acknowledge this, even though its goals are broadly similar.