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: =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <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, 2 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).