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

Mark Andrews <marka@isc.org> Wed, 01 November 2017 01:32 UTC

Return-Path: <marka@isc.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 81DD813F5B9 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 18:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 NpzCpkByeLRx for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 18:32:03 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 04DD213F586 for <dnsop@ietf.org>; Tue, 31 Oct 2017 18:32:03 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CA8A63AF0D0; Wed, 1 Nov 2017 01:32:00 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8E1FC16006D; Wed, 1 Nov 2017 01:31:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A9F9160064; Wed, 1 Nov 2017 01:31:53 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y8puofUleXu7; Wed, 1 Nov 2017 01:31:53 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 26CC0160048; Wed, 1 Nov 2017 01:31:53 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D9F968DD6042; Wed, 1 Nov 2017 12:31:50 +1100 (AEDT)
To: Paul Vixie <paul@redbarn.org>
Cc: Paul Wouters <paul@nohats.ca>, Edward Lewis <edward.lewis@icann.org>, Moritz Muller <moritz.muller@sidn.nl>, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <olafur@cloudflare.com>, "dnsop@ietf.org" <dnsop@ietf.org>
From: Mark Andrews <marka@isc.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> <59F8D666.9000808@redbarn.org>
In-reply-to: Your message of "Tue, 31 Oct 2017 13:00:38 -0700." <59F8D666.9000808@redbarn.org>
Date: Wed, 01 Nov 2017 12:31:50 +1100
Message-Id: <20171101013150.D9F968DD6042@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-T5KKAJI0ODSCsWVGrIvW1TCzGY>
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: Wed, 01 Nov 2017 01:32:04 -0000

In message <59F8D666.9000808@redbarn.org>;, Paul Vixie writes:
> 
> 
> Paul Wouters wrote:
> > On Tue, 31 Oct 2017, Edward Lewis wrote:
> >
> ...
> >>>> ConfiguredKey-trumps-DS
> ...
> >>
> >>> It better, it is the only working solution :)
> >>
> >> Can you elaborate...why would it be the "only" "working" solution?
> >
> > The idea of the hierarchical model has always been that if you don't
> > trust the parent, you can configure keys at the level you want. If
> > I don't trust the root, I can put in a trust anchor for .ca. If I
> > don't trust .ca, I can put in a trust anchor for nohats.ca.
> 
> +1. and this is how DLV worked, for that reason.

DLV is deepest match.  It also was was only consulted if the answer
validated as insecure with configured trust anchors.  No trust-anchor
above a name means it validated as insecure.

The same data could be used to configure trust anchors which are
used instead of DS records.  Named currently doesn't support this.

> > Allowing "any" key to override that would make me vulnerable to all
> > my parents, even if I don't want to trust them. I don't want .ca to
> > be able to put in a DS for internal.nohats.ca in their TLD and steal
> > my traffic. Now, when I run that zone internally and sign it internally,
> > and put in the trust anchor, this zone can never be stolen from me by
> > a parent.
> >
> > This has always given the parent keys an enigma problem. Get abused once
> > and we will bypass you. Trusting "any" key will no longer allow me to
> > untrust a particular zone cut.
> 
> +1. all policy is local.
> 
> -- 
> P Vixie
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org