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

Paul Wouters <paul@nohats.ca> Thu, 09 November 2017 05:01 UTC

Return-Path: <paul@nohats.ca>
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 4963B12954C for <dnsop@ietfa.amsl.com>; Wed, 8 Nov 2017 21:01:27 -0800 (PST)
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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 D1BVI7WEPvgj for <dnsop@ietfa.amsl.com>; Wed, 8 Nov 2017 21:01:26 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279911242EA for <dnsop@ietf.org>; Wed, 8 Nov 2017 21:01:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yXWGW2kC5z38M for <dnsop@ietf.org>; Thu, 9 Nov 2017 06:01:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510203683; bh=CJhuOGmIxwNhQSuQZNhCvQArZKu3ZL5YvA+uQkl9Xns=; h=Date:From:To:Subject:In-Reply-To:References; b=gucfMVyQpBNVG/ngpS+FO+YtgyXgv2i64/Itj/0npkQTnMVvvBm1xDsdlGI/CjCs2 fO5eOxYYPDJdHuyxBwsq36d0ks4Dba0V3m0ob4Gcn8Ei8t8MVxcXHj5qrKMeC3Ceg8 SpFNgVPxpIpRchHhfO8WyviDBSWBXe2UAmJaygQI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LSIW9dDQacBc for <dnsop@ietf.org>; Thu, 9 Nov 2017 06:01:21 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Thu, 9 Nov 2017 06:01:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id A1F9D62D29; Thu, 9 Nov 2017 00:01:19 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A1F9D62D29
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7FC0F40D35AF for <dnsop@ietf.org>; Thu, 9 Nov 2017 00:01:19 -0500 (EST)
Date: Thu, 9 Nov 2017 00:01:19 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org>
Message-ID: <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>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pTv5AxvWEVweNykQRMBOXjE7l_0>
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 05:01:27 -0000

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.

> 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