Re: [DNSOP] Resolver behaviour with multiple trust anchors

william manning <chinese.apricot@gmail.com> Sat, 11 November 2017 05:09 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 4EF8712941D for <dnsop@ietfa.amsl.com>; Fri, 10 Nov 2017 21:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 Wir-VGhYbKji for <dnsop@ietfa.amsl.com>; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 BA7C2128B51 for <dnsop@ietf.org>; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
Received: by mail-it0-x230.google.com with SMTP id m191so3988110itg.2 for <dnsop@ietf.org>; Fri, 10 Nov 2017 21:09:47 -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=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=f54gPBjiDSELxu4XA6Tfg0wVj6BSHPnPegxRJ5sgTU8RyaqueW41pKQxLgL3Q41dvX bjzljNiNPQVuDvy3I/vOPSTag2a+VRucd81XhQ6TzCqSYsaGCCr43tipW9opNwDTbp4d MiuVIPxjQThWjVFmf7CD+tE8i9GzSEOGOkyqzh50+EP+yL+9cc+CBrJDK+jU/K76rSMs anbDT6I9BvKDIZYiKaiVICcXyvNhmG1a90ThOBo/MHZJnenlOzOj09zELWuAG7XRj7Yz eUNCiD753WkUtP62cFLHt7vKKodjIAqmX/wvX0DuP3NMqgRx19NCa5db5IwEsULMFtKN FYAw==
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=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=leQEN/tOE0SNlF9/x6EYdO9rUUXuO4tqq4SdK8ZeWt46ZU+C9veZwxm5h94cMcze39 bBWZgG6sFA/Tq1YSFPYJPL41/a9/z24IzbkipWHxV29DXYe+Az7ZlRMRvLuUvf0Czc3t 2ijO1ojnsTQclv+95SPRut+8+iCIoNvYiFd+fK+maOJ5iUmTGifWYoLs8F/DuQd+8yLZ jHAuKDikbEyFT3dlxnhrxLHQ5fFwbpnwPIEZmdbrFppD08ha/K6J3r2X45A8WpBFWd/M Fv57wVbcOiQslDiIX2rVJlvL5mS9f2+NhpOL1M2eGzHonAHInO/fnHEDdRfVxfMdd5jq DEDg==
X-Gm-Message-State: AJaThX5OZxmoHKcHJGrUh0+pWr7BwwB/S68DG2yMibLo83TcB5lb+zbG TeVcYfmA8TPzThtJl2XrY7Ym33bde/3GvGCDUAM=
X-Google-Smtp-Source: AGs4zMaLq9mBrWo4iDv00Mvp+HbqUXg3XiUahbruzIfYoCQAYySd1GpyM36/pqXpPV/BALVz1fvXevLH0MGWfdG2VKo=
X-Received: by 10.36.181.82 with SMTP id j18mr3309896iti.18.1510376987072; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.7.42 with HTTP; Fri, 10 Nov 2017 21:09:46 -0800 (PST)
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: william manning <chinese.apricot@gmail.com>
Date: Fri, 10 Nov 2017 21:09:46 -0800
Message-ID: <CACfw2hg5vyqcxuAVzYG-8M5Sx95YZyWQOTqqgBhCmZqJyhStvQ@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>, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045d9d8cca9c63055dae0bfe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F6mmyEde81PxQu17Bqk1FIrkZDs>
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:09:50 -0000

in the last 20 years, there have been a few testbeds that have explored
this space.

irl.cs.ucla.edu/papers/imc71-osterweil.pdf
https://eprint.iacr.org/2013/254.pdf

that suggest Matt is spot on here.   accepting any success is likely to
present the fewest problems from a user perspective.

/Wm

On Thu, Nov 2, 2017 at 7: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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>