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

Ondřej Surý <ondrej@isc.org> Sun, 29 July 2018 08:55 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 74401130E7A for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 01:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1ir2h7LDRbzf for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 01:55:36 -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 E2C0C130E3C for <dnsop@ietf.org>; Sun, 29 Jul 2018 01:55:36 -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 4EDC93AB003; Sun, 29 Jul 2018 08:55:35 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3F09416006C; Sun, 29 Jul 2018 08:55:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2B900160069; Sun, 29 Jul 2018 08:55:35 +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 s8VAu8h_p5iY; Sun, 29 Jul 2018 08:55:35 +0000 (UTC)
Received: from [100.101.176.193] (ip-37-188-144-179.eurotel.cz [37.188.144.179]) by zmx1.isc.org (Postfix) with ESMTPSA id CF78F160055; Sun, 29 Jul 2018 08:55:34 +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: <alpine.OSX.2.21.1807290047300.46393@ary.qy>
Date: Sun, 29 Jul 2018 10:55:31 +0200
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2923107-B7D1-4ED6-AAC6-C65553BDEFEB@isc.org>
References: <20180728215805.E60F020030A8E0@ary.qy> <FC43CF7A-9653-4EF3-BFF5-79600DC940AD@isc.org> <alpine.OSX.2.21.1807290047300.46393@ary.qy>
To: John R Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VPvXOF_vAq7pOgAzmcKV0dyzzIM>
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 08:55:39 -0000

Mail headers doesn’t have NSEC records.  Also any operation where you need to reconstruct the file by combining bits from different places/channels is prone to errors.

You need to know the hash is valid before you start the download. Therefore the hash has to be signed.

O.
--
Ondřej Surý — ISC

On 29 Jul 2018, at 06:50, John R Levine <johnl@taugh.com> wrote:

>> 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, ...).
> 
> Of course you exclude the hash record from the hash.  Look at the way we do DKIM signatures -- the header hash includes all the headers including the signature header, but it pretends there's no hash field in it.
> 
> I'm also thinking the hash wouldn't need to include the RRSIG records, since those are mechanically derived from the underlying records and the ZSK.
> 
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly