IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

Edward Lewis <edward.lewis@icann.org> Mon, 13 November 2017 15:45 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 60B371205F1 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 07:45:37 -0800 (PST)
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 GVzfnRpQPKDI for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 07:45:34 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 D76FB1242F7 for <dnsop@ietf.org>; Mon, 13 Nov 2017 07:45:32 -0800 (PST)
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.1178.4; Mon, 13 Nov 2017 07:45:30 -0800
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.1178.000; Mon, 13 Nov 2017 07:45:30 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: Evan Hunt <each@isc.org>, Petr Špaček <petr.spacek@nic.cz>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Configured Trust Anchor vs. DS record
Thread-Index: AQHTWWiXPRp7CRP4/kG/0ZKc0dRV56MMpuMAgAAyMoCABicTAA==
Date: Mon, 13 Nov 2017 15:45:30 +0000
Message-ID: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org>
References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <b21647d7-a710-e5f7-048f-d90eccc79c0f@nic.cz> <20171109174804.GA63012@isc.org>
In-Reply-To: <20171109174804.GA63012@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3593414730_1453672502"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qpgx2k-uPFQKgz9EvoKN9xrSybM>
Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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 Nov 2017 15:45:37 -0000

On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" <dnsop-bounces@ietf.org on behalf of each@isc.org> wrote:

>    On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote:
>    > Nice write-up Edward! You have nicely summarized why Mark and me agree
>    > that validator should use longest suffix match when selecting TA to
>    > validate data.
>    
>    +1.

Hmmm, that wasn't my intent. ;)  I had been trying to justify the other conclusion.  But, if my work is leading you towards this "other" conclusion, I've been taking time to understand why.

I'm beginning to have a new understanding on this.  The overlooked (by me) point is that we are focusing on a situation where the local operator has chosen to explicitly configure a trust anchor.  Beside code distributions shipping with the IANA managed KSK (or its DS form) for the global public Internet's root zone, if any operator wants another trust anchor point, they have to take explicit action to configure it.  The question is - what is the expectation of the operator in doing this?

There was a time when TLDs were signed but the root zone was not.  Then operators had to configure trust anchors for the TLDs to enable validation.  When the root zone was signed in 2010, the TLDs had to remind all those with trust anchors to remove them (before the TLD could change it's KSK).  I can no longer find reports of the efforts to undo TLD trust anchors (Sweden and maybe CzechRep?) that I thought were once floating around.  "Fears" surrounding this would lead one to favor the more open "any" policies, on the other hand, mass migration from TLDs to root for the top of the trust chain was probably a one-time event as a result of the on-set of DNSSEC in the root zone.

I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore.

OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks).  I'm not sure if robustness helps here, or is a bad-behavior enabler.

>    > Things might get even more complicated when negative trust anchors are
>    > configured, bleh.
>    
>    Fortuantely a negative trust anchor is a longest suffix match too.

This is an emerging "thing" - more active awareness and management of the trust anchor element of a validator.

v2.14.0 | Report a Bug | By Email