IETF Logo Mail Archive

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

Frederico A C Neves <fneves@registro.br> Wed, 15 November 2017 03:27 UTC

Return-Path: <fneves@registro.br>
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 21FAE1294C8 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 CGKiMmP7-YAT for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:27:02 -0800 (PST)
Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4551292D3 for <dnsop@ietf.org>; Tue, 14 Nov 2017 19:27:02 -0800 (PST)
Received: by clone.registro.br (Postfix, from userid 1000) id 3252B2101F6; Wed, 15 Nov 2017 01:27:00 -0200 (BRST)
Date: Wed, 15 Nov 2017 01:27:00 -0200
From: Frederico A C Neves <fneves@registro.br>
To: Edward Lewis <edward.lewis@icann.org>
Cc: Evan Hunt <each@isc.org>, Petr Špaček <petr.spacek@nic.cz>, "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20171115032700.GE94801@registro.br>
References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <b21647d7-a710-e5f7-048f-d90eccc79c0f@nic.cz> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6yF0Ywqkn-CceK7aoYmQz2RmCRE>
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: Wed, 15 Nov 2017 03:27:04 -0000

On Mon, Nov 13, 2017 at 03:45:30PM +0000, Edward Lewis wrote:
> 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.
> 

Yes. And add to that cases were TLDs rolled just before adding to the
root.

https://eng.registro.br/pipermail/gter/2010-May/027981.html
https://eng.registro.br/pipermail/gter/2010-June/028053.html
https://eng.registro.br/pipermail/gter/2010-July/028138.html

Fred

v2.23.0 | Report a Bug | By Email