Re: [DNSOP] Resolver behaviour with multiple trust anchors

william manning <chinese.apricot@gmail.com> Sat, 11 November 2017 05:11 UTC

Return-Path: <chinese.apricot@gmail.com>
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 5DA1B1200C1 for <dnsop@ietfa.amsl.com>; Fri, 10 Nov 2017 21:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D1jfvjJl2BzL for <dnsop@ietfa.amsl.com>; Fri, 10 Nov 2017 21:11:41 -0800 (PST)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 99DE1126C23 for <dnsop@ietf.org>; Fri, 10 Nov 2017 21:11:41 -0800 (PST)
Received: by mail-io0-x241.google.com with SMTP id d66so15662888ioe.5 for <dnsop@ietf.org>; Fri, 10 Nov 2017 21:11:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=U1386XhDcb/pq3vzZvq0IgnfmRY9iu1t7d91JbX3ZRVBrRB85m44Q/a2GQ60hub7GR NQ7OESzwRWTYWMxsnf7VwOwPzgwdP/9BydPx8DWc3aaoRla1beypdC7LMdMWsy6V9v5l s9XZDmAmYeGPkilvcG5Pu/95/sHx7UjE1ZdXvfxXMtU/N/Ue2fWn/VHjzpqA8zavTr9v JBR3IogvgVkqvJARz6bBZPRNGDdeDaVdVj1+foNLFQWoU0ir3OIDwop5OX098mZHeDyQ Y8iA3jn11tv5OFG8Jq+eedJK3Jmj7r9T/HcWuk9cHsvOV6MvRWH0sqPQSIWpkMx/7sty j38A==
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=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=RrOPT8V/B67tC2NOO/0nTuoDlzCSc7m60WvIDJ8lg2OSOPHF3gFleFPoNZSL5ObJye Dxy/Qfy0Ef6eZWMM6YKYgeJhTd4LetnyLcw2w1mfLv2/zKahwbJ3CHxqPDmsmPiJWphy QkTsAFnmoVTVTsh0Sah7mzcvaJE8GKWKQfEHnsYm72eZkvZqt/KqdnUBt/sN8yQwo4KK Osz74GogfC4lYHdT8LdXyvnzd950slr2qSOtkjMcb6dQbpiWI4VVZ71DuArSXTCcE3WA /2gKo2weNv+05+8ifd3/TlAXPdQVWaUMYCj5J52PbxMttLt9fmqPzlXACZDt8I+hfEeP DHxg==
X-Gm-Message-State: AJaThX7VN0KF2/oyMgdUMOsVzdsIKHNjdNempAJTxKtQL1xXQPPA38s+ OkDowhnE65OcticlmaO0aRbdr3WwlforpXZrkHU=
X-Google-Smtp-Source: AGs4zMa0L8fG8A+IVNN/gKy7WtSWjoTSMtZ1fxCauvIpPxom6cYjgOwUGLEzCkvNbZzgcp2W+NzPRfRSFSJls0lUhIo=
X-Received: by 10.107.139.144 with SMTP id n138mr2931171iod.173.1510377100895; Fri, 10 Nov 2017 21:11:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.7.42 with HTTP; Fri, 10 Nov 2017 21:11:40 -0800 (PST)
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: william manning <chinese.apricot@gmail.com>
Date: Fri, 10 Nov 2017 21:11:40 -0800
Message-ID: <CACfw2hg1K1KYJMrsA2NyuCRdN-3KNfRLQsH9MYuUq6jh-HSipg@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: multipart/alternative; boundary="94eb2c058680936b89055dae12f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6gk1T1MLIg9_K5uESt-D7eqXoYk>
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: Sat, 11 Nov 2017 05:11:44 -0000

in reverse order of trustworthiness:

the root
a third party - e.g. DLV
locally verified - e.g. my employer, ISP, someone I have a binding legal
relationship with

/Wm

On Thu, Nov 2, 2017 at 8: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?)
>
> 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
>
>