Re: [DNSOP] Resolver behaviour with multiple trust anchors

Matt Larson <matt@kahlerlarson.org> Thu, 02 November 2017 14:41 UTC

Return-Path: <matt@kahlerlarson.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 8B51013F9BD for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 07:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level:
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] autolearn=no 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 TOpRmK9VbnIi for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 07:41:38 -0700 (PDT)
Received: from smtp85.ord1d.emailsrvr.com (smtp85.ord1d.emailsrvr.com [184.106.54.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCA013F9B3 for <dnsop@ietf.org>; Thu, 2 Nov 2017 07:41:38 -0700 (PDT)
Received: from smtp19.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id B81E560088; Thu, 2 Nov 2017 10:41:37 -0400 (EDT)
X-Auth-ID: matt@kahlerlarson.org
Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 72EC760072; Thu, 2 Nov 2017 10:41:37 -0400 (EDT)
X-Sender-Id: matt@kahlerlarson.org
Received: from [10.96.9.25] (44-2.dc.icann.org [192.0.44.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Thu, 02 Nov 2017 10:41:37 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Matt Larson <matt@kahlerlarson.org>
In-Reply-To: <alpine.LRH.2.21.1710311541090.23568@bofh.nohats.ca>
Date: Thu, 2 Nov 2017 10:41:35 -0400
X-Mao-Original-Outgoing-Id: 531326495.305648-488b616488d48c0bfecafdc47f8b37dd
Content-Transfer-Encoding: quoted-printable
Message-Id: <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.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>
To: Paul Wouters <paul@nohats.ca>, Ed Lewis <edward.lewis@icann.org>, Moritz Muller <moritz.muller@sidn.nl>, =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= <olafur@cloudflare.com>, "dnsop@ietf.org" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K0SpBLElpJcQe5xHc0693JxJ6eg>
Subject: Re: [DNSOP] 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 14:41:39 -0000

The root KSK rollover project has given me a real appreciation for the brittleness of trust anchor configuration, even with RFC 5011. (Automated update support should get better over time, especially after the first KSK roll exposes problems, but right now it's pretty shaky, which is my informed opinion based on observation from the operational trenches.) In the real world, where trust anchors are going to go stale, an "Accept Any Success" (in the language of Appendix C) trust anchor policy is the safest operationally.

I agree with Ed's observation that operators are, by and large, going to use the defaults in whatever implementation they're running, so defaults are important.

Trust is always going to be a matter of local policy, so with DNSSEC there's never going to be a consistent output given a consistent input. The best we can do is give good guidance to implementors, ideally based on operational experience, to inform their choices for the default settings that operators will end up using.

I think RFC 6840 gets it right: it acknowledges that trust anchor preference is a matter of local policy, but recommends an operationally safe default of "Accept Any Success".

Why would one want a "Closest Encloser" trust anchor preference policy? I've heard two reasons in this thread:

1. The untrusted parent scenario: I submit there's no practical implication of distinguishing between the parent's control of the delegation and its control of the DS: the child zone is completely at the will of the parent zone, so if your parent has it in for you, you lose. This scenario is not sufficient motivation, in my opinion, to suggest "Closest Encloser" as a default policy.

2. In a split DNS context, reject answers that leak into the wrong view: I think using DNSSEC as a backstop to enforce split DNS policy is a dubious operational practice and likewise not sufficient motivation to suggest "Closest Encloser" as a default policy.

In my perfect world, implementations would offer a knob to set "Closest Encloser" for consenting adults but default to "Accept Any Success".

Matt