Re: [DNSOP] Resolver behaviour with multiple trust anchors
Bob Harold <rharolde@umich.edu> Thu, 02 November 2017 15:04 UTC
Return-Path: <rharolde@umich.edu>
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 B674813FA5A for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 l9KHAcD6-nEf for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:04:53 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8117D13F92E for <dnsop@ietf.org>; Thu, 2 Nov 2017 08:04:53 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id a192so5364897pge.9 for <dnsop@ietf.org>; Thu, 02 Nov 2017 08:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0BCqiF+91mxqdKUcQdRF8h4nLA/AWiw+g8aiKdWQbzc=; b=GL9jJtAZDc5BMapa2nljfyOK2QWpA6lBGlt7MOnVOI+riEoN+Cq33/Q2+nyR8zWhyU MoFNfCL0OX/z+iSXhWa7qlC3GR4xUYz9sxurHOUbakBt2V51NAzcQ25dd4jy7vV4Cq3W ZOEVezR2jksIOHBPk7bynQZ6BToPngcZ/eV7TfcrXdGNFsM+iKq9kd4NgbfT+HpvzTUM APvaYYUQt0BuaHm/8kgNBeCLHGxOQijC/y8jpiPC4mAl8aMz12qh1AF6m43S/7AwUC0h nv1Z0mSZQgde7uXwpEtYyLHOlkzja2pyqfxlEQ/KPq9nM9zjOs3tqgxYawe9fi6jSku4 XoKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0BCqiF+91mxqdKUcQdRF8h4nLA/AWiw+g8aiKdWQbzc=; b=gw+3ohyjx1sGkHySqZG0YZxDA+Ffx9VrJKeTk3S0YO/3J5TSZFWDEguugnCKlVC/w6 J3SDm/5cxRMIjZg5r0iL7UZsUHZK6EY1Z2s30HiQUz26ythB7KOP3pbd//txDBnVYRfC q5lJcsLQ0blsEhNrI45wp3Uk1K7jRQ5pQwiIyUbHFgF7ihzgNSf3hgOgAeYjqJdzvh1c SjQfTneig5qCVo7NK7zbYHQSIxwlJftxTndVcx2p7rALdJZ/WBlQnHUuqrBG26ePQyVU naCp/o85ds5tr0h5eBWl4jwDP6jYTjBxoAMRYZA7JU3cDUo9sbot3CE/r/UgmqCIYo7p miwQ==
X-Gm-Message-State: AMCzsaXP1yeaHM64dRULvj1F5zdbWcy5hI5Vl5ataVxm/LKEGSjZwkEY TvdmGxsKk3fL9vQ7oZz8wzarExZS4AvmeGm9ZBCM7w==
X-Google-Smtp-Source: ABhQp+Sz74+sgTQ3R/vo8E2tf6J1Sz50ek1T23de1l2xJfkVgwsaB5fdys/icNX3f6fE+CJEVhgAF0c15XGOYJcrKlw=
X-Received: by 10.99.112.29 with SMTP id l29mr3895374pgc.2.1509635092970; Thu, 02 Nov 2017 08:04:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.4 with HTTP; Thu, 2 Nov 2017 08:04:52 -0700 (PDT)
In-Reply-To: <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> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 02 Nov 2017 11:04:52 -0400
Message-ID: <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com>
To: Matt Larson <matt@kahlerlarson.org>
Cc: Paul Wouters <paul@nohats.ca>, Ed Lewis <edward.lewis@icann.org>, Moritz Muller <moritz.muller@sidn.nl>, Ólafur Guðmundsson <olafur@cloudflare.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c749c751387055d014f80"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/syeQelyiOe4FUl4KRdyqARRlEq8>
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 15:04:56 -0000
On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <matt@kahlerlarson.org> wrote: > 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 > I generally agree with you, but wonder if there is a performance penalty to searching every possible path before failing. Is that a reasonable concern? How many paths are there? I can think of: 1. To the root 2. To a local trust anchor 3. To a DLV provider (gone as of Sept 30?) If local trust anchors are checked before the root, and they are under operator control, then maybe "Closest Encloser" is a reasonable default. I don't know where to fit DLV into that plan. Also, if an operator does not configure DLV or local trust anchors, then is root the only path? So "Closest Encloser" and "Accept Any Success" are the same? Or am I not understanding something (no experience with this yet)? -- Bob Harold
- [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