IETF Logo Mail Archive

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

"John R Levine" <johnl@taugh.com> Sat, 28 July 2018 16:13 UTC

Return-Path: <johnl@taugh.com>
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 4ED38130EF9 for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 09:13:18 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Ulje5JFT; dkim=pass (1536-bit key) header.d=taugh.com header.b=tLqqL8xj
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 VI1m_wW9T5rj for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 09:13:16 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5133C130E74 for <dnsop@ietf.org>; Sat, 28 Jul 2018 09:13:16 -0700 (PDT)
Received: (qmail 24099 invoked from network); 28 Jul 2018 16:13:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5e1f.5b5c961a.k1807; bh=DvWPcAdhMtaRNwz3IoheJhlCoMP6p8TdL0Z8PtDIxzQ=; b=Ulje5JFThUWFj9ZQzafaDBSWBEkN6bTYiUd95cLMmBQnGjMGTREiGNHOKjmRITDHEk0Et7NpLDu5QBvaTpx7u+AkFWF5v1EN2SFjVE2foNV5Lh/BiW2gyPYHsav6fo6mFRnfZk9Qu/Dko2Q9jEQlgBpppHkc3prrVt2/GfTvxHqK9FYkMFLmx9DQHnSvx4AVR2szKEVn9+ierEHsYUyz6HXQeD7v3cA+FeLPcVFd3vu9xqepC/z2KNN62+WIe9xh
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5e1f.5b5c961a.k1807; bh=DvWPcAdhMtaRNwz3IoheJhlCoMP6p8TdL0Z8PtDIxzQ=; b=tLqqL8xjduIvz5YG2LIDfWd5mNnMvuL8krcfWRjvtJh2rz+tdpK6umgXg9N2VTW4PC4XqC7JKyE/dII5UUs6I9IsemGSXm8sSzAlaTF+r7y8SBYwji+dVa3v7IrhNo0hSqr4CX7N91Ts1T1U0nLdJM+QezNlCgd0GyU551ULYGYAH7wATZunJo3Ug2Xy6CLV4JCNOQ2CA27NMwhtaVVp1GOvr50detUsnaHp089goIwDc7KCHpYKnvvffxbcpsFb
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 28 Jul 2018 16:13:14 -0000
Date: Sat, 28 Jul 2018 12:13:13 -0400
Message-ID: <alpine.OSX.2.21.1807281207520.72264@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: dnsop@ietf.org
In-Reply-To: <87k1pfgy5i.fsf@mid.deneb.enyo.de>
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>
User-Agent: Alpine 2.21 (OSX 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/hqMa_N3Wpi6sU2Ub41Clfhsmpmc>
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 16:13:18 -0000

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.

On the other hand, I don't see any particular reason that the ZONEMD 
couldn't have a field for the number of records, and it goes at the apex 
of the zone so you'd expect to find it near the front of the file.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

v2.23.0 | Report a Bug | By Email