Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
Edward Lewis <edward.lewis@icann.org> Thu, 02 November 2017 15:41 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 8308413F82F for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IRdcSgyXdtyZ for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:41:52 -0700 (PDT)
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 E92E113F44D for <dnsop@ietf.org>; Thu, 2 Nov 2017 08:41:52 -0700 (PDT)
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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 08:41:51 -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.1178.000; Thu, 2 Nov 2017 08:41:51 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Warren Kumari <warren@kumari.net>, Bob Harold <rharolde@umich.edu>
CC: Ólafur Guðmundsson <olafur@cloudflare.com>, Matt Larson <matt@kahlerlarson.org>, Moritz Muller <moritz.muller@sidn.nl>, Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors
Thread-Index: AQHTU+i9bgXp0SADEEG6x6vd1yaJ3qMBpWUAgAAGKACAAAQsAA==
Date: Thu, 02 Nov 2017 15:41:51 +0000
Message-ID: <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com> <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <alpine.LRH.2.21.1710311541090.23568@bofh.nohats.ca> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com> <CAHw9_iJ5dYaHQOSnhSg2cGq8aa+fNPR8KsdR_xB=zVdtMANgKg@mail.gmail.com>
In-Reply-To: <CAHw9_iJ5dYaHQOSnhSg2cGq8aa+fNPR8KsdR_xB=zVdtMANgKg@mail.gmail.com>
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_3592467710_1414157198"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ltXTfkpMUhTVBZlJ5Pjlv7CNMRs>
Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
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: Thu, 02 Nov 2017 15:41:54 -0000
On 11/2/17, 11:27, "DNSOP on behalf of Warren Kumari" <dnsop-bounces@ietf.org on behalf of warren@kumari.net> wrote: > Having a (per-TA) knob sounds like a nice compromise, but I'd really > like implementors to chime in on how much complexity this adds. If *I* > added a local TA for .example (or foo.example.com) I'd automatically > assume that this is a closest encloser / Negative Trust Anchor / > longest match type operation and would be very surprised if that > wasn't the behavior -- this *may* be a combination of being primarily > a routing person, and also the fact that if I create a local zone for > foo.example.com (in a non-DNSSEC world) I'd expect it to take > priority... This is an interesting viewpoint. I understand that in the routing world, longest match prefix is the way the outgoing interface is chosen. This doesn't translate into the design of DNSSEC though. (Like a pun in English isn't quite the same in any other language and vice versa.) The issue in routing is that you have to choose one solution and go with it. Unless you are multi/broadcasting, the packet is going to go on to one outgoing buffer/queue. The issue in DNSSEC is to retain as much robustness as possible because the decision will have a long-lasting impact (sitting in cache, opening an ssh connection, etc.) This mirrors what Paul said in an earlier message regarding PKIX. On 11/2/17, 11:11, "DNSOP on behalf of Paul Hoffman" <dnsop-bounces@ietf.org on behalf of paul.hoffman@vpnc.org> wrote: >The consensus conclusion was that any performance penalty was worth the consistency of answers, since the relying part (the stub resolver in our case) had no control over the order of evaluation. Consistency is the objective there, not robustness, but I'd hand-wave the two are closely related. Consistency, in terms of coherence, has historically been part of the DNS rhetoric, which (I'll claim) is a/one foundation for DNSSEC's robustness. So, I get that from a routing backdrop, the longest match expectation is reasonable but not what was written into the DNSSEC documents because DNS and DNSSEC have different objectives than routing (or forwarding, whichever is more appropriate).
- [DNSOP] Resolver behaviour with multiple trust an… Moritz Muller
- Re: [DNSOP] [Ext] Resolver behaviour with multipl… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple trus… Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple trus… Michael StJohns
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Wouters
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Vixie
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Michael StJohns
- Re: [DNSOP] Resolver behaviour with multiple trus… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Patrik Wallstrom
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Ólafur Guðmundsson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple trus… Matt Larson
- Re: [DNSOP] Resolver behaviour with multiple trus… Bob Harold
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Warren Kumari
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple trus… Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple trus… Joe Abley
- Re: [DNSOP] Resolver behaviour with multiple trus… Brian Dickson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple trus… Lanlan Pan
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple trus… william manning
- Re: [DNSOP] Resolver behaviour with multiple trus… william manning