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

Paul Wouters <paul@nohats.ca> Tue, 31 October 2017 19:52 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 3A2CE13F61B for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 12:52:28 -0700 (PDT)
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 gLdSAoMJAbeJ for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 12:52:26 -0700 (PDT)
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 5ED3013F614 for <dnsop@ietf.org>; Tue, 31 Oct 2017 12:52:26 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yRMSk3LGYzFBF; Tue, 31 Oct 2017 20:52:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509479542; bh=wY4UAxjlnw4Yz602R5adkbdSG5mC7vfLneJqIOKmX2A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dU9G0FO174T+UcnS+8PafPiTILtLEtIjZGL/ToA5TDD3FHecvPvFFSsw0T9G/WF2z g3Oz5oeGm+ap/+zEP3fpM3MnojS6vg87eno3oTMprJWwrduX4MJPP1HPgiAVY6A93v m4ZmD+waoEhDImQ7Hih56BMtBzSKdt+Wt+U1lmUw=
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 4wm8iO_Fd2LN; Tue, 31 Oct 2017 20:52:20 +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; Tue, 31 Oct 2017 20:52:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A79762D29; Tue, 31 Oct 2017 15:52:19 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8A79762D29
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 78E2440D35AF; Tue, 31 Oct 2017 15:52:19 -0400 (EDT)
Date: Tue, 31 Oct 2017 15:52:19 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Edward Lewis <edward.lewis@icann.org>
cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= <olafur@cloudflare.com>, Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org>
Message-ID: <alpine.LRH.2.21.1710311541090.23568@bofh.nohats.ca>
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>
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/ubWYzIHIwmBp4fGTjEdJXpYGtvk>
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: Tue, 31 Oct 2017 19:52:28 -0000

On Tue, 31 Oct 2017, Edward Lewis wrote:

>>> Any-TrustedKey-works
>>> ConfiguredKey-trumps-DS
>>> DS-trumps-configuredKey
>>>
>>> But I suspect the middle one is implemented
>
>> 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.

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.

Paul