IETF Logo Mail Archive

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

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 06 November 2017 16:08 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 6E07913FAD9 for <dnsop@ietfa.amsl.com>; Mon, 6 Nov 2017 08:08:20 -0800 (PST)
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] autolearn=ham autolearn_force=no
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 mKCE_q-mE7nq for <dnsop@ietfa.amsl.com>; Mon, 6 Nov 2017 08:08:19 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6ADE913F698 for <dnsop@ietf.org>; Mon, 6 Nov 2017 08:08:19 -0800 (PST)
Received: from [10.32.60.122] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA6G6q61073581 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Nov 2017 09:06:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.122]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop@ietf.org
Date: Mon, 06 Nov 2017 08:08:17 -0800
Message-ID: <B3CE8833-F17B-484F-9FC1-288BEA716EF1@vpnc.org>
In-Reply-To: <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2NEPeC2lH7DZh_fl4kURdQvyTAE>
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: Mon, 06 Nov 2017 16:08:20 -0000

On 6 Nov 2017, at 7:56, Petr Špaček wrote:

> 2. Vast majority of people will not bother with setting up own trust
> anchors. I.e. vast majority of people will not be affected by any
> brittlenes you envision.
>
> 3. The small fraction of people who configure their own TA do it for a
> reason. The reason I can see is "TA pinning". This provides users
> ability to to configure their critical systems in a way which turns
> successfull hack into my parent registry into Bogus status.
>
> Yes, it requires them to keep TA up-to-date, but that is the price you
> pay for pinning.

In retrospect, I agree that these two are good justification for "if a 
subordinate trust anchor has been configured, the default is to trust it 
more than the superordinate one" as long as the document also says "but 
this should be configurable".

So, are you volunteering to start the effort for rfc6840-bis? :-)

--Paul Hoffman

v2.23.0 | Report a Bug | By Email