Re: [DNSOP] Resolver behaviour with multiple trust anchors

Warren Kumari <warren@kumari.net> Thu, 02 November 2017 15:27 UTC

Return-Path: <warren@kumari.net>
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 58007139680 for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 3Y3uOZq2c95F for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 08:27:37 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 09AD313FA9F for <dnsop@ietf.org>; Thu, 2 Nov 2017 08:27:37 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id p96so5373956wrb.7 for <dnsop@ietf.org>; Thu, 02 Nov 2017 08:27:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vlDJyD4Kog8LnHHbdikxMdrZglmI9dHQ1hEN7Xavwho=; b=z7S0uK4xlrza982pWXCYZ/9N+scFpEeZ51VEnJMdjGtSPHGENPdTMfY9hgG+4BI/Jg 41IZN/dA4occr9+ckg1ckkoP4ErDeF51mMR0V33U5hPI3Zx8avbyQn1hG1dmYFAp39ir FoM2lZGhx+2F0CP6clRMRX81vKpJhXe7epyVGOHj9r24IbqvnlQ6p7kNYpMGmNWQvJe4 FokZaJZ67yoc0HZjbCmQNfIDndzobyh+4obABmKLDzDxyctBYck/3LnpoMvjVnPKe6V+ KjFKSJhvfhy4TVWuca0lPbKeZQEfklRTXx13jK2toiCzgjOMx3HBFV6JZRaKm7L1kNAa t82A==
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=vlDJyD4Kog8LnHHbdikxMdrZglmI9dHQ1hEN7Xavwho=; b=cX0lp7RIUpAAUvkycnJfwLFBlE5MvrtQKqRhVpmh+B1aclKfa7YPpItb3EBZzcHW/Q RgIH3nbqOBKO5Qkc98+pDQTcb/aRMwHdEWrfayQir2boiyQgdbGk4GdaQW+/pHGfiuud ng6ilnyEbz+gd7LZEDr/kw7ds6njSACGdsStKs3YvhudUig8FazKuNnTajf+iON/91/0 v8+CQKl+ffyE1p9oleXRrs42dll1X1mu0/1hPZMJJhIvTBOwyqAGPPY2W6r6/FIXhNKO mL62H5R9ZmhZSNcVw+iT1yca/pLCLJz/5XAuWc0tBPTKyRUrBvrzR9evwigprgehy+fN 5VtQ==
X-Gm-Message-State: AMCzsaUtY3d+Ft989MhzRsLOU4jM2tIl7cp1F9nFxsba/gspWisKw0ni 9rJiLPE9Pa29Mnef0X8Sy64QqHOb59cXqM0Si8Iziw==
X-Google-Smtp-Source: ABhQp+SaNctSvvm61wOZDw8/74XNAXJuJbQgOA2fKEgbaVx7t/iHbS2h0za0b7b4shuosjs2VE/5lewfDTRQi+EkrL8=
X-Received: by 10.223.187.143 with SMTP id q15mr3111324wrg.184.1509636455213; Thu, 02 Nov 2017 08:27:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.12 with HTTP; Thu, 2 Nov 2017 08:26:54 -0700 (PDT)
In-Reply-To: <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com>
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>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 2 Nov 2017 11:26:54 -0400
Message-ID: <CAHw9_iJ5dYaHQOSnhSg2cGq8aa+fNPR8KsdR_xB=zVdtMANgKg@mail.gmail.com>
To: Bob Harold <rharolde@umich.edu>
Cc: Matt Larson <matt@kahlerlarson.org>, Ed Lewis <edward.lewis@icann.org>, Moritz Muller <moritz.muller@sidn.nl>, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>, Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UqQCM5HY0q7TsdnTeRh2_8Srr0k>
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:27:39 -0000

On Thu, Nov 2, 2017 at 11:04 AM, Bob Harold <rharolde@umich.edu>; wrote:
>
> 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?)

I have no actual data, so I'll pontificate instead :-)

I suspect that there is a really small set of resolvers with more than
just the root TA -- and if the resolver operator *has* configured a
local TA they have done this for a reason important to them, and so
presumably are willing to pay the performance cost.

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...

W

>
> 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 mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf