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

Edward Lewis <edward.lewis@icann.org> Mon, 13 August 2018 17:25 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 2DE58130FA6 for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 10:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yJEaPJ6z-KpS for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 10:25:15 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E72124BE5 for <dnsop@ietf.org>; Mon, 13 Aug 2018 10:25:15 -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; Mon, 13 Aug 2018 10:25:13 -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; Mon, 13 Aug 2018 10:25:13 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
CC: John Levine <johnl@taugh.com>
Thread-Topic: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02
Thread-Index: AQHUMx1RgcQejTWkS0KFdY3XnrmfnqS+IT4A
Date: Mon, 13 Aug 2018 17:25:12 +0000
Message-ID: <55C39266-40BA-4266-B631-28050CCE8242@icann.org>
References: <7223EEB4-57A4-4C54-8C62-631B5FBEE0A5@icann.org> <20180813154946.A0D5020036E99E@ary.qy>
In-Reply-To: <20180813154946.A0D5020036E99E@ary.qy>
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: <5174EDDEB9ED80489342407F9B3F0F8B@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wS2On3RaB5lCWs4t0ty0HawQvsw>
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: Mon, 13 Aug 2018 17:25:16 -0000

On 8/13/18, 11:50, "John Levine" <johnl@taugh.com> wrote:

>As we may have mentioned once or twice before in this discussion, it lets you do zone transfers over insecure channels and batch verify the zone before using it.

Yes, I see that.  As in no more argument is needed to convince me of that.

>but the obvious consumer is a DNS server.

Maybe, maybe not.  I've seen DNS used in turnkey ways.  Nevertheless, given the complexity of DNSSEC validation, a wise implementer should re-use the parts of a DNS server for this.

(I.e., there's a lot of wacky stuff out there.  See "DNS Zone Transfer Protocol (AXFR)", Definition of Terms section [RFC 5936, Sec. 1.1] definitions of "General-purpose DNS implementation" and "Turnkey DNS implementation.  I've run across a lot of weird stuff in my studies of responder behavior [shuddering to think of these beasts as servers ;) ].)

>it'd be nice to be able to check that the zone is correct and get notified of failure

There are many existing tools for such a set up.  For one, use a VPN or in-band channel security, and/or make sure the zone file received matches the zone file sent.  (If you use AXFR, which can only run on TCP, make sure the first and last resource record are the SOA.  If you use RSYNC, use other filesystem checks - like file size for one.)

I think the use case is the "we'll put the zone on some third party server and let others [the second party] retrieve it" - that's where you would want an end-to-end "secure" set up.

This is where my "belts and suspenders" comment comes in, if whatever uses data sets from the zone as transferred will do DNSSEC validation on the sets, what's the need for a signed "checksum" of the whole zone?  What is the relying party does not do validation?

In essence, what would do DNSSEC validation for the ZONEMD and not for data sets within the zone?