Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

Edward Lewis <edward.lewis@icann.org> Fri, 10 August 2018 13:18 UTC

Return-Path: <edward.lewis@icann.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 26A77130DC8 for <dnsop@ietfa.amsl.com>; Fri, 10 Aug 2018 06:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fViQrZJ96dkZ for <dnsop@ietfa.amsl.com>; Fri, 10 Aug 2018 06:18:07 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A674412F18C for <dnsop@ietf.org>; Fri, 10 Aug 2018 06:18:07 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Aug 2018 06:18:05 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Fri, 10 Aug 2018 06:18:05 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
CC: Paul Wouters <paul@nohats.ca>
Thread-Topic: [Ext] Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02
Thread-Index: AQHUL+vvqpBp9iR+tEaWUlJrtzK1fKS4lcYAgAAAnQCAAJUzAA==
Date: Fri, 10 Aug 2018 13:18:05 +0000
Message-ID: <2204181E-9433-4B93-B240-92FF754A2468@icann.org>
References: <6D6060CF-FD20-4D79-BF98-A4BE77011741@icann.org> <20180810002152.GA55133@straasha.imrryr.org> <43D819E7-581C-4B62-9F9A-99A6F9497B9B@nohats.ca>
In-Reply-To: <43D819E7-581C-4B62-9F9A-99A6F9497B9B@nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.d.0.180513
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FA021C794011534CB47CC226D8D0821B@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0ovIqDVy1L8fzQBODBJ7ny2fpY8>
Subject: Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02
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: Fri, 10 Aug 2018 13:18:09 -0000

On 8/9/18, 20:24, "DNSOP on behalf of Paul Wouters" <dnsop-bounces@ietf.org on behalf of paul@nohats.ca> wrote:

>The point was to allow redistribution and to not depend on a trusted source 

That, FWIW, is the heart of DNSSEC.  Source authentication and data integrity for data sets is the advertised goal (as well as provable non-existence) of the extensions.  The DNS is not a strict client-server protocol, there is no telling what path a resource record (set) would take from the zone administrator to the would-be validating receiver.

Originally the set of paths included authoritative servers, forwarding servers, recursive servers, iterative servers, and such down to the point where DNSSEC validation could no longer be done.  (Originally, CPU horsepower and reliable libraries weren't assumed to me on end devices, hence the stub resolvers aren't included.  No reason they couldn't, no reason applications can't validate, except for performance/trust anchor management concerns.)

Now we are envisioning the transfer of zones in bulk, not just single datasets, via non-port 53 means.  But is that any different?  Does it really matter whether RSYNC of a zone was used to get a dataset from A to B?

There is a concern I can see.  When a server is loaded from disk (secondary storage), it does not validate the DNSSEC records to save time.  There's a risk that a maliciously inserted zone version be loaded and served, possible if the channel security is defeated.  But, if that happens, validating recipients of data sets will fail the data sets that are altered.  While this could be a denial of service for the server, but DNS provides fallback to other servers so relying parties are just as protected as they ordinarily are (including, no DNSSEC, no protection...).

How realistic is it that a forged zone could defeat all of the channel security for a zone?  How likely would it be for someone to load a false zone on all the places a recursive server would look for it?  Answering that would be a crucial step in deciding whether to add a zone hash mechanism.