IETF Logo Mail Archive

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

Edward Lewis <edward.lewis@icann.org> Tue, 14 November 2017 14:44 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 453FE126C0F for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 06:44:49 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 LcgNFvtLQ7Ca for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 06:44:47 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 B319712426E for <dnsop@ietf.org>; Tue, 14 Nov 2017 06:44:47 -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; Tue, 14 Nov 2017 06:44:45 -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; Tue, 14 Nov 2017 06:44:45 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: Paul Wouters <paul@nohats.ca>
CC: Evan Hunt <each@isc.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Petr Špaček <petr.spacek@nic.cz>
Thread-Topic: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
Thread-Index: AQHTXO52tQkp3dARdE2OI0U03tcjj6MUencA
Date: Tue, 14 Nov 2017 14:44:45 +0000
Message-ID: <7FE86715-53B2-4C9E-ACFE-22465B0E75EF@icann.org>
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> <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca>
In-Reply-To: <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca>
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_3593497484_1473080730"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XDuJFF-m4qA5B_37_DWBfxbLBg0>
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: Tue, 14 Nov 2017 14:44:49 -0000

On 11/13/17, 21:15, "DNSOP on behalf of Paul Wouters" <dnsop-bounces@ietf.org on behalf of paul@nohats.ca> wrote:

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

>But that’s not your call to make, but the call of the entity deciding to put in that hard-coded trust anchor.

To clarify, the "robustness" was the goal of the protocol design leading up to the 2004 publication of the current DNSSEC definition, it's not a call anyone is making now.

The goals of robustness, local policy, and other factors fed into the current design.  How these, sometimes conflicting, objectives were weighted was subjective and with more 20/20 hindsight, perhaps the weightings were wrong.
    
>We just ask you not to block us from doing as we have been doing for years.

I don't know how to take this - what's being discussed is the way the protocol was designed in the past versus how implementations have chosen to go.  In the spirit of code trumps spec, then specifications need to catch up if there's a deviation.

>I would like split-DNS to die too but I dont think that’s happening soon.

Arguing split-DNS would be another thread, I want to clarify that the "too" in your quote shouldn't implicate anything I've said about split-DNS meaning I wished it to "go away". (I.e., I see split-DNS as a reality.)

v2.23.0 | Report a Bug | By Email