Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Ólafur Guðmundsson <olafur@cloudflare.com> Thu, 09 November 2017 14:17 UTC

Return-Path: <olafur@cloudflare.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 B545E1200F3 for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 06:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 F9CgpMOrB5dX for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 06:17:11 -0800 (PST)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 952D5124319 for <dnsop@ietf.org>; Thu, 9 Nov 2017 06:17:11 -0800 (PST)
Received: by mail-wr0-x232.google.com with SMTP id j15so5729782wre.8 for <dnsop@ietf.org>; Thu, 09 Nov 2017 06:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9LvNclAUu2+8ud2P3QWNE8HPSL+6ZTyi4LZFWdinmkc=; b=fVtgLfN9yc3iQLVlzmTITfuzqqUW0/31tS58c4XBG/q06F8AIdrparG5CmlX1O0fOW Cqm3xTfalNwrUjy6Dgkas/L5bbsHHv+gIfP3x/MuClRZ0Vj3O7RjyQwXAiSfLvYjPTmg XmBbc8vWJ8czorh0vPzAFTjdicHkRFvHPOPbQ=
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=9LvNclAUu2+8ud2P3QWNE8HPSL+6ZTyi4LZFWdinmkc=; b=TUl3eXE9SKLk4xmHdBkAMN5zqTXOD2gLLTyh4MNfbkVwqWNrHFzZyeG46SQSyJjyz4 TbSUoTqv6o4Ga1fFU7OdbUVLNrcebH+spxdZ1HfG3HjceoTGvEtXNpotJPgeSL1JIHga Xgj1cLzqxAhOZSRSdvsyRIiaFTWKOc45TZjPKf9QSp0SijGnOOlWuQeUa8Qf5bHILxyu T4B0mwI46pGuG2yFP4xm0XaNCEsOjbtqxqsx3z0Q56sWqhPkNbLszVnmBiNG3DRuO6S/ iqz3hDcnJ6ISuuakDJbrdGaG3r++Tap8EXig2j9Hdk172seP/U8aOOKIH5NMClfpZqHc q95A==
X-Gm-Message-State: AJaThX4MUzcrX37GqhJA3ugyYmi8Wvnw09xQUELsLn2uQ3mNn2f5oQCt i+6WvHIDxkVlRKcFvSpFPMrr8XfEe7Drrl5l/tl5kQWW
X-Google-Smtp-Source: ABhQp+Tr0HE8qCFyMmrlWeb0L/6MF6zXbXGE4LXKuJW1BO6RRjrQqYGZiKgdQqmxZuiTDDZ0qqNL2fLTj4UVSXg2i8k=
X-Received: by 10.223.187.3 with SMTP id r3mr582825wrg.34.1510237029983; Thu, 09 Nov 2017 06:17:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.201.10 with HTTP; Thu, 9 Nov 2017 06:17:09 -0800 (PST)
In-Reply-To: <alpine.LRH.2.21.1711082355370.18444@bofh.nohats.ca>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> <alpine.LRH.2.21.1711082355370.18444@bofh.nohats.ca>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Thu, 9 Nov 2017 09:17:09 -0500
Message-ID: <CAN6NTqwHWbmxganQywidzSvxpJDUVEJD6oBVEmJBa=YOLS=_pA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="089e0821528cb2f43f055d8d75a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O9uIFRHnjJ-gboC2TGP7h9Z2U4M>
Subject: Re: [DNSOP] [Ext] Re: 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, 09 Nov 2017 14:17:14 -0000

On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters <paul@nohats.ca>; wrote:

> On Wed, 8 Nov 2017, Edward Lewis wrote:
>
> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibility that knobs can be
>> included, which is the prerogative of the implementer to build and the
>> operator to use (local policy).  I see these two documents as compatible.
>>
>
> "prerogative of the implementer" canont apply to how one defines trust
> in a protocol. You can't have two implementations make different
> trust decisions, especially as most endusers don't control their
> resolver.
>
>
Paul,

I have been thinking about what you said and why it is perfectly valid, but
that I think it is wrong.
The issue here is three fold IMHO
Operator is using split-DNS i.e. internal and external
Operator is using the SAME name space for both views  i.e. foo.example.com
can exist in both name spaces with different values.
Operator is using DIFFERENT keys to sign the two namespaces.

We have no way at the moment to express  which namespace a "name" comes
from thus you want to give preference to the "internal" namespace for users
of that namespace

The purist in me says this is bad setup, the practical part of me says "you
get what you ask for" i.e. IETF failed to write guidelines for Spit-DNS
thus we should expect things like this.
Either way I think the use of Different Key is what we should strongly
discourage as that makes the other problems go away.

The bottom line is that one can choose to abide by a rule of "if a trust
>> anchor is there, ignore other chains" but recall that the choice is made by
>> the validator operator, not the zone administrator, as the validator
>> operator is also responsible for keeping the trust anchors current and
>> accurate, it is their own failure if that is not the case, and they
>> exclusively have the ability to fix a conflict.
>>
>> The bottom line is that the zone administrator doesn't get a say - it's
>> all up to the validator operators.
>>
>
> It's up to neither. You cannot retroactively argue that hardcoding trust
> anchors is an option can that be ignored by an implementation.
>
> knot had a bug some people thought would be a nice fallback recovery
> feature to a failed rollover procedure. knot should just be fixed. This
> really does not require an RFC update.
>
> Paul
>
> Olafur