Re: [DNSOP] Incremental zone hash - XHASH

Wes Hardaker <wjhns1@hardakers.net> Mon, 30 July 2018 23:52 UTC

Return-Path: <wjhns1@hardakers.net>
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 7C8B8130F61 for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 16:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 ryQ-UogfLhOo for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 16:52:50 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D086130F25 for <dnsop@ietf.org>; Mon, 30 Jul 2018 16:52:50 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id B90E724645; Mon, 30 Jul 2018 16:52:49 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Wouters <paul@nohats.ca>
Cc: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>
References: <FA63BBB1-5AB1-4494-85A9-B43CB2A04F89@isc.org> <CAKr6gn1axEztD06WoH0a+=WGjrzPNSiYWtk-qLzKY0BWprCVwA@mail.gmail.com> <alpine.LRH.2.21.1807221443170.5582@bofh.nohats.ca> <CAHw9_iK1W-CeA+ppJWggzCDhTwdi-jhGZOe6D44XfRJNeSginA@mail.gmail.com> <alpine.LRH.2.21.1807251300490.24159@bofh.nohats.ca>
Date: Mon, 30 Jul 2018 16:52:49 -0700
In-Reply-To: <alpine.LRH.2.21.1807251300490.24159@bofh.nohats.ca> (Paul Wouters's message of "Wed, 25 Jul 2018 13:09:14 -0400 (EDT)")
Message-ID: <ybl8t5s7032.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HVPBrLAhjv--16UrA5zy0P5-Ahs>
Subject: Re: [DNSOP] Incremental zone hash - XHASH
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: Mon, 30 Jul 2018 23:52:53 -0000

Paul Wouters <paul@nohats.ca> writes:

> That leaves glue and NS, but there is a reason those aren't signed,
> and any attacker shouldn't get anything out of that by modifying it.

Yes, the glue isn't authoritative and thus not signed by DNSSEC.

But, if you're transferring a zone from an original source to any
secondary server that is redistributing the contents, then modification
by an attacker can certainly do damage (though with fully deployed
DNSSEC, it may be only a DOS; though without fully deployed it's much
worse, and we're a long way from fully deployed on both ends).

The question of need comes down to: regardless of how it's done, do we
need a global zone data signature across the entire set of distributed
data that survives multiple distribution hops.  From the perspective of
wanting to distribute data across a multitude of mechanisms (including
DNS but all git, bittorrent, http, and Warren's dirty napkin), then
there is value to having a verifiable checksum.  That's why software
packages are distributed in the same way: verify that what you got is
authentic before using it.

-- 
Wes Hardaker
USC/ISI