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

Brian Dickson <> Tue, 28 April 2020 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FCBB3A09EE; Mon, 27 Apr 2020 17:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F21RwA_cKJjb; Mon, 27 Apr 2020 17:43:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79BBD3A09EB; Mon, 27 Apr 2020 17:43:17 -0700 (PDT)
Received: by with SMTP id y10so19618714uao.8; Mon, 27 Apr 2020 17:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MoxIt5xtgjJC3hEmKEsu5UUiKNdAOra/7iyFeardxfY=; b=jOBmsXaZFDmD0cCwOypJCDSMt3TnsLEWQl8zSIgKTUguYKWdpGDRm9Lf3m1RaHoIaj WcH+fUWeCraclS8+3dEZolmCaAIXoFj2ufI35DvAde6ajfOMzYrX+Eed7AqR7zZQhtuB TNEED1/Qx1vnCHyi/S3cweKlkzkAYTA5SWLVbJyKDGb4PW7AZ8ftlvUlPFxvNW2GMIzg km4eTQFwOodojN7gE6WIjHp2JnMxJxclfdkqFt5n6I/asBtU6ij0HwqW7BG8WltQhlr9 BVF0CH2U0ZG8fZHwQjZPFFKsoN264iiSeeI1EPvMqtefZMkxKipLKPuZiKQSFOcNmIAZ Ltqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MoxIt5xtgjJC3hEmKEsu5UUiKNdAOra/7iyFeardxfY=; b=bYFF8uKzIy7sK9yZ6i1YwTA5OKBt7qmhIXJostxGYYtcGOWF/8JWXXINJvpYTcc930 RylnfLsW0V8zYm5I8j8b4HwwOCuWbnUPLuBRJloh/pvKPJZd/oKNv7t22WsXw4q0y/Ps MrTuFyA+UaZknuLfhUAAjCdVTakCUMDdrdRY8ttIZtZhTEOK35YvessV2KHtz1Xs6x2l 6R6JQU784+8zoGwvxxnr3BrOeQ/0Mp2MGlWZFlGC2vvTdFY3M8b4f2+kzRx3rnIwqXyo Me/CtvRbu4ujWm+2mA3JdG77Ph7Q/pIbx/CpI36IhlHADmxe0psmqkblUbg5bd+2s2GS RrVA==
X-Gm-Message-State: AGi0PuZp8KeHHuh2AJTByheNvHWItH56TqYPVbW/EA3y0Dmz3He7q0Od wR/IhRLiCBfIXSNknLkDcACWIhKf1Fm1/cU8mMF/0A==
X-Google-Smtp-Source: APiQypLF9QfspM6m8MgU/jGN/dI8VpTWpasoeFgn45w8rpcXNMGa8CDngwYRN+01R8XN9sAKu4yFcAXMYDVt9hdgCzc=
X-Received: by 2002:ab0:700f:: with SMTP id k15mr19105059ual.75.1588034596307; Mon, 27 Apr 2020 17:43:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 27 Apr 2020 17:43:05 -0700
Message-ID: <>
To: Wes Hardaker <>
Cc: Joe Abley <>, Tim Wicinski <>, dnsop <>, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="0000000000000107ab05a44f1ec4"
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Apr 2020 00:43:20 -0000

On Mon, Apr 27, 2020 at 3:28 PM Wes Hardaker <> wrote:

> Joe Abley <> writes:
> > This draft needs a more compelling problem statement, and a clear
> > description of why other controls (e.g. reputational, contractual) are
> > insufficient. [It's also possible that the draft just needs a clearer
> > problem statement, rather than a more compelling one.]
> Hi Joe,
> Thanks for the comments.  I'm working on a more clear rewrite of the
> introduction.  I'd love your feedback on it once I get it wrapped up.  I
> think (hope) I can spell out the case for support more clearly.  I agree
> the subject is a bit hard to wiggle into your head (as are most
> somewhat-complex security cases)
Hi, Wes,

I was looking at the draft to see if I understood the intent correctly, and
I think there may be a small gap, if my understanding is correct.

So, I think there are two use cases that something doing this kind of thing
needs to handle.

One is the "flat delegation-only zone", like any of the big well-known ones
(com, net, org, info).

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).

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.

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

With the addition of an explicit set of ENTs, there would be double-entry
Entries in the zone with depth > 1 would require a chain of ENTs to the
zone apex.
Entries in the zone with depth == 1 would need to not also have
corresponding ENTs.

(My assumption is the ENT declarations would be separate from the intrinsic
ENTs from NSEC or the explicit ones from NSEC3, if I recall my NSEC vs
NSEC3 nuances, and probably in a sibling zone like _ent.TLD for example.)

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

The two example zones I would reference would be ".uk", and ".jp", where
there are SLDs immediately below the TLD, and additional SLD-like
delegations or non-delegations further down in the zones.