IETF Logo Mail Archive

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

Ondřej Surý <ondrej@isc.org> Sun, 29 July 2018 04:35 UTC

Return-Path: <ondrej@isc.org>
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 865FA130DC7 for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 21:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 lbThDBM_kiC4 for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 21:35:25 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 45D42130DC5 for <dnsop@ietf.org>; Sat, 28 Jul 2018 21:35:25 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 086D33AB003; Sun, 29 Jul 2018 04:35:24 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E70BE16005B; Sun, 29 Jul 2018 04:35:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C09CD160069; Sun, 29 Jul 2018 04:35:23 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EyKRxjoMfjFx; Sun, 29 Jul 2018 04:35:23 +0000 (UTC)
Received: from [10.10.0.183] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 3146516005B; Sun, 29 Jul 2018 04:35:23 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ondřej Surý <ondrej@isc.org>
X-Mailer: iPhone Mail (16A5327f)
In-Reply-To: <20180728215805.E60F020030A8E0@ary.qy>
Date: Sun, 29 Jul 2018 06:35:20 +0200
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC43CF7A-9653-4EF3-BFF5-79600DC940AD@isc.org>
References: <20180728215805.E60F020030A8E0@ary.qy>
To: John Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7ZUygxN7vmj_KAlQYwiUO5k69Ag>
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 04:35:27 -0000

The way BitTorrent works, it’s basically a Merkle tree over the chunks. So, you need to compute the main hash over the zone data.

Maybe there’s a smart way to compute hash over the data that includes that hash, but my poor brain thinks it would break the Matrix (or at least the hashing function).

Therefore either you need to exclude the data that changes (hash and its RRSIG) when computing the hash for the BitTorrent and the receiving side would have to reassemble this. Or you would need OOB mechanism to distribute the hash (different part of the tree, CDN, ...).

Ondřej 
--
Ondřej Surý — ISC

> On 28 Jul 2018, at 23:58, John Levine <johnl@taugh.com> wrote:
> 
> In article <208F049B-B35A-4755-9A20-FA0C7F6855CF@isc.org> you write:
>> a) the hash has to be independent to zone, so either the hash has to reside outside of the root zone, or the root zone file would
>> have to be reconstructed with “the torrent hash” and “the torrent data”; generally you would want the hash to be signed,
>> so the TORRENT RR + RRSIG would have to be distributed outside of the data received via BitTorrent
> 
> I'm confused again.  Why couldn't the hash RR and sig be in the zone
> just like any other record in the zone?
> 
> R's,
> John

v2.23.0 | Report a Bug | By Email