IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: zonemd/xhash versus nothing new

Edward Lewis <edward.lewis@icann.org> Wed, 01 August 2018 12:02 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 F2DB0130F4A for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 05:02:55 -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 ILxK9I4HCPGE for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 05:02:52 -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 2925C13102D for <dnsop@ietf.org>; Wed, 1 Aug 2018 05:02:52 -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; Wed, 1 Aug 2018 05:02:50 -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; Wed, 1 Aug 2018 05:02:49 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] zonemd/xhash versus nothing new
Thread-Index: AQHUKAnPZ0BpXcAZe0KtGhHYw2Zs3KSpW0IAgACIBQCAARiSAIAAP0YA///GOYA=
Date: Wed, 01 Aug 2018 12:02:49 +0000
Message-ID: <8BA61349-D576-4508-BB35-C652BBF4086F@icann.org>
References: <alpine.LRH.2.21.1807271758580.22024@bofh.nohats.ca> <alpine.DEB.2.20.1807301424400.3596@grey.csi.cam.ac.uk> <a6226b2d-957a-7953-3a17-67a7282984bb@nic.cz> <alpine.DEB.2.20.1807311549150.3596@grey.csi.cam.ac.uk> <45f16f82-4a06-b194-a6e5-da0a230527c0@nic.cz> <alpine.DEB.2.20.1808011228080.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1808011228080.3596@grey.csi.cam.ac.uk>
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: <E77F904E069D2C45B1FB8A7F9ED2BEF9@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F0oQpAsRP5zC36RGHnNkZ7in2tQ>
Subject: Re: [DNSOP] [Ext] Re: zonemd/xhash versus nothing new
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: Wed, 01 Aug 2018 12:03:02 -0000

On 8/1/18, 07:29, "DNSOP on behalf of Tony Finch" <dnsop-bounces@ietf.org on behalf of dot@dotat.at> wrote:

>I was kind of assuming that the NSEC chain would include the glue -
>obviously delegations and glue in opt-out intervals are not protected at
>all.

The reason cut point information is not signed is that the copies are not authoritative, that is, the delegating zone is not the source of the records, they are merely hints.

The reason this wasn't seen as an oversight is the thought that if bad glue were followed, the DNSSEC chain would not work (for the data set sought) so long as the private keys (involved) were private.

The reason there is no overall zone signature is that the goal was data (set) integrity, not zone transfer integrity.

If the issue is zone transfer integrity, a solution will need to go beyond what DNSSEC is defined to be now.  (Not saying this is an obstacle, pointing out that DNSSEC wasn't designed to do accomplish that.)

FWIW, there's TSIG protection of AXFR messages (hop-by-hop), which isn't DNSSEC and then other operational practices, as examples of other tools.  (That is obvious to many, just including for completeness.)

v2.23.0 | Report a Bug | By Email