Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Edward Lewis <edward.lewis@icann.org> Thu, 09 November 2017 13:29 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 A8A241242F5 for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 05:29:39 -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, RCVD_IN_DNSWL_MED=-2.3, 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 aUaCnem_8QON for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 05:29:37 -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 C09A31201FA for <dnsop@ietf.org>; Thu, 9 Nov 2017 05:29:37 -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; Thu, 9 Nov 2017 05:29:35 -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; Thu, 9 Nov 2017 05:29:35 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
Thread-Index: AQHTVumQ9Sx/szK9UESN2BoiNrPbqKMH/JGAgAALagCAA0vtAIAAs/CAgACN/4A=
Date: Thu, 9 Nov 2017 13:29:34 +0000
Message-ID: <B17E4899-8E2D-468C-B821-D50EC9404BA7@icann.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> <alpine.LRH.2.21.1711082355370.18444@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1711082355370.18444@bofh.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_3593060973_13227723"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lHCdLv5HhfloRlA5xoOvb3cMYjQ>
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, 09 Nov 2017 13:29:40 -0000


On 11/9/17, 00:01, "DNSOP on behalf of Paul Wouters" <dnsop-bounces@ietf.org on behalf of paul@nohats.ca>; wrote:

>"prerogative of the implementer" canont apply to how one defines trust
>in a protocol. You can't have two implementations make different
>trust decisions, especially as most endusers don't control their
>resolver.

The first split I make when considering this is the difference between general purpose implementations - such as BIND, Unbound, Microsoft's, and others that are distributed to a general population - and turn-key implementations which are purpose built for a specific need.  The latter do exist, are generally not considered when it comes to standards as, for them, conformance to open standards just doesn't matter.

For general purpose implementations, it is up to the distributor of the software to decide what and how to implement.  Whether to faithfully implement a Request for Comments is a choice.  I have been witness to an implementation that tried to fix itself to be more compliant only to find the relying parties balking, requesting a return to the non-conformant behavior.

When it comes to DNS resolution, there is the basic protocol to implement - the messages, the formats, timing, etc.  If not done correctly, a resolution engine may suffer rcode=FORMERR and get nowhere.  But there is a lot of choice for an implementer and still remain interoperable with other software builds.

One feature is what I've often called the "aggressive nature" of searching for an answer.  Neglecting DNSSEC for the moment, in 2012 I tried to write a basic resolver to find information about a popular ranking engine's top zones.  I discovered that many of the zones were "broken" in the sense that the servers operating them did not answer queries for SOA, NS, etc., errors that should have made the zones unreachable.  Yet these zones were ranked as popular.  I realized that general purpose resolvers went beyond the basic strategy for getting an answer, I mentally tagged this as "aggressive resolution".  In the same sense that an experienced librarian may find a reference book that an inexperienced one may not.

DNSSEC offers more choice in terms of aggressive resolution.  For example, if a resolver is suffering a forgery attack (a'la what Kaminsky described long ago now) the first response the resolver would get is the forgery.  If the resolver waited longer, the real answer would likely arrive.  Early, and as far as I know still true for current, resolvers close their listener after getting the forgery.  It is possible to continue listening (but for how long?) to get the real answer.  With DNSSEC proving the first answer wrong, the real answer could be validated - if the listener is not torn down.  I understand why this more aggressive implementation was not chosen.

There is much leeway in what an implementer chooses to encode.  The goal of the RFC series, early on at least, was to give guidance on how to allow interoperability.  The documents are not requirements nor design guides.  I spent a long time with "The Algorithm" in section 4.3.2 of "Domain Concepts and Facilities" (part of STD 13) to come to know what that means.  (Thanks to Rob Austein.)

Implementers, like any kind of writer, have to put their audience foremost in mind.  This is why there are many extra-standards features (and bloat) in software today.  (Round-robin deliver of answers worked its way into mainstream code that way.)  Implementers have to balance simplicity of tools with functionality via complex configurations.  I've been told that many times the operator will just go with the default settings - so that is important.

>It's up to neither. You cannot retroactively argue that hardcoding trust anchors is an option can that be ignored by an implementation.

I don't understand this point.  If you are referring to the practice of general purpose code shipping with a set of trust anchors, at least in BIND one can turn DNSSEC off - or remove/override the packaged defaults.  That is useful when deploying code on a network that is not the global public internet.
    
>knot had a bug some people thought would be a nice fallback recovery feature to a failed rollover procedure. knot should just be fixed. This really does not require an RFC update.

It's not clear whether the "bug" was a "feature you didn't like" or a coding error from this statement, so I don't know what the latter sentence is saying.

I realize I'm writing a lot, and I'm not sure I'm making a strong enough case about why "for the sake of resiliency" any chain that validates ought to be taken as a good thing.  This might take a different approach as trying to talk about "trust" is too ill-defined when discussing a protocol whose basic design did not consider "trust" regarding the data delivered.  "Trustworthiness" in "Clarifications to the DNS Specification" relied on what section the data appeared in a response and from what IP address it came.  Forgeries weren't considered even in that round of clarification.