Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
Edward Lewis <edward.lewis@icann.org> Tue, 31 October 2017 19:33 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 AC72913F5B7
for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 12:33:22 -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, 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 SF84IZm1EYoU for <dnsop@ietfa.amsl.com>;
Tue, 31 Oct 2017 12:33:21 -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 6693013F5C6
for <dnsop@ietf.org>; Tue, 31 Oct 2017 12:33:19 -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; Tue, 31 Oct 2017 12:33:17 -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; Tue, 31 Oct 2017 12:33:17 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Paul Wouters <paul@nohats.ca>, =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?=
<olafur@cloudflare.com>
CC: Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors
Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+vEmAgAABTICAABGcgA==
Date: Tue, 31 Oct 2017 19:33:16 +0000
Message-ID: <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
<CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com>
<E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca>
In-Reply-To: <E94AE36A-CA69-47DB-A2B7-41D0C3644855@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_3592308796_152919435"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VKYheNWvnKD6U_ZAOs7cGbFuj0Y>
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: Tue, 31 Oct 2017 19:33:23 -0000
On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" <dnsop-bounces@ietf.org on behalf of paul@nohats.ca> wrote: > On Oct 31, 2017, at 22:25, Ólafur Guðmundsson <olafur@cloudflare.com> wrote: >> >> There are three ways to treat this case: >> Any-TrustedKey-works >> ConfiguredKey-trumps-DS >> DS-trumps-configuredKey >> >> But I suspect the middle one is implemented >It better, it is the only working solution :) Can you elaborate...why would it be the "only" "working" solution? I understand that "Any-TrustedKey-Works" would be hard on implementers (I recall a day when one of the original DNSSEC developers didn't like doing something because it made the code ugly), but it's the one that maximizes robustness. ("What if:" The trust anchor manager was off-line during the time when an Automated Updates [STD 69] revocation was signaled?) Finding the closest trusted encloser ("trusted" meaning there's a trust anchor data, as opposed to a simple "closest encloser" determined by existence) is simple, finding and handling the list of all trusted enclosure points would make the coding ugly. That's the only rationale I'd see for not follow a philosophy of "Any-TrustedKey-Works."
- [DNSOP] Resolver behaviour with multiple trust ... Moritz Muller
- Re: [DNSOP] [Ext] Resolver behaviour with multi... Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple tr... Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple tr... Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple tr... Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple tr... Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple tr... Michael StJohns
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Wouters
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Vixie
- Re: [DNSOP] Resolver behaviour with multiple tr... Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple tr... Michael StJohns
- Re: [DNSOP] Resolver behaviour with multiple tr... Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple tr... Patrik Wallstrom
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple tr... Ólafur Guðmundsson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple tr... Matt Larson
- Re: [DNSOP] Resolver behaviour with multiple tr... Bob Harold
- Re: [DNSOP] Resolver behaviour with multiple tr... Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple tr... Warren Kumari
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple tr... Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple tr... Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple tr... Joe Abley
- Re: [DNSOP] Resolver behaviour with multiple tr... Brian Dickson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple tr... Lanlan Pan
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with m... Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple tr... william manning
- Re: [DNSOP] Resolver behaviour with multiple tr... william manning