Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Paul Wouters <paul@nohats.ca> Tue, 28 April 2020 02:43 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 A9A863A0CE6 for <dnsop@ietfa.amsl.com>; Mon, 27 Apr 2020 19:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 zYuNtuAVDrMe for <dnsop@ietfa.amsl.com>; Mon, 27 Apr 2020 19:43:54 -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 922D03A0CE1 for <dnsop@ietf.org>; Mon, 27 Apr 2020 19:43:53 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49B5Z002gYz3Ft; Tue, 28 Apr 2020 04:43:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588041832; bh=vj2Hd0VBWrg+1rllTGNPivT+w3KJNmrSyz9QgglvkZo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NQDHLTUKbvofkuOR8lo0YqpGzDKjhxUbpMZJts4OnyHlBecTB+3aGbFSIWUlVsGxU 8WJpsWiNKV45AcOCAlzX8JR+SjIK9BeVo5BdV3lCjEd1IftS7XqtJFyhBkxEpsL3/K r69WEsn6m7COeByQadTXxhTfWBa9fIjIgH/rFTKo=
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 B7omcNwvPPF8; Tue, 28 Apr 2020 04:43:50 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Apr 2020 04:43:50 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CD2BC6020D44; Mon, 27 Apr 2020 22:43:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C960F66B7C; Mon, 27 Apr 2020 22:43:49 -0400 (EDT)
Date: Mon, 27 Apr 2020 22:43:49 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Brian Dickson <brian.peter.dickson@gmail.com>
cc: Wes Hardaker <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>
In-Reply-To: <CAH1iCiom2O0tYSF=_kskGZP4vymQGqvVjhswEHBfodMKKdHA_g@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.2004272230560.5715@bofh.nohats.ca>
References: <CADyWQ+FLrTy0gy8iCyAPsDpiumDNQHX4TGPni43ThA=W3fmZew@mail.gmail.com> <EB400743-8B25-45DA-B4BD-5B27F47AE9E3@hopcount.ca> <ybl4kt48sxq.fsf@w7.hardakers.net> <CAH1iCiom2O0tYSF=_kskGZP4vymQGqvVjhswEHBfodMKKdHA_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B4pY35hoL_qg6Njr1iNcz5DDA3k>
Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Apr 2020 02:43:56 -0000

On Mon, 27 Apr 2020, Brian Dickson wrote:

> The other would be the kind that are multiple-depth delegation zones, where the Public Suffix List is already kind of necessary.
> 
> What I think is needed is a way to explicitly declare the places where the depth is > 1 (if a normal flat delegation-only zone has depth == 1).

We thought about using two bits instead of one, so we could specify a
variable depth (per zone, not per delegation) but it seemed to add a
lot of complexity. It is far easier for these TLDs to make their ENTs
a signed delegation.

> And that would effectively just need a way of making permanent and well-known, the set of ENTs for the zone (empty non-terminals).
> 
> I think that list is likely to be short even for the most convoluted zones..

Doing things in more variable ways with lists of exceptions to a depth
== 1 seems very complicated and would add complexity for resolvers.

> Without this, it would be theoretically possible for the TLD to add additional unsigned delegations to bypass a signed delegation.

I do not understand this? You mean leaving the ENT unsigned, and then
adding NS records to create a false shadow tree? At best that would
result in DS records for the real delegations to be ignored because
there is a validation error in the path. Or if the DS records would
still be served signed from the parent, then this hostile takeover
via unsigned records would not work because the shadow tree would not
have the DNSKEYs matching the signed DS record.

> If two delegations were present, child.example.com and example.com, it would not be possible to disambiguate them without knowing more about the zone
> structure and semantics.

This is an interesting case I had not considered. If a TLD hands out
domains in a mix of 1 level and 2 levels deep, what can be done
other than not using this draft? If the ENTs are limited, then
I'd still be tempted to say to turn those into real signed zones.
Any mechanism that would convey this list of ENT's would really
complicate things far more than just turning the ENTs into real
signed zones.

Paul