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

Joe Abley <> Fri, 24 April 2020 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 856783A0D04 for <>; Thu, 23 Apr 2020 18:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sMxjxAwm7X_L for <>; Thu, 23 Apr 2020 18:37:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D96B53A0D05 for <>; Thu, 23 Apr 2020 18:37:22 -0700 (PDT)
Received: by with SMTP id l78so8692025qke.7 for <>; Thu, 23 Apr 2020 18:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=niLX3fP+qb29CZcYqzjJsKB8IPoHuBgk/o2Wh/Novak=; b=GKqCZkWVk2qyHzauy/pefJ88cxCPG/+B817DVIE9mzTXPSdOldErSy8HYem5D7yuTV ECob95h16OqsWNerWY+9BhR+9WTCmkOuHk1nOBRBYC+MuObyoxU4q0P5YaX78CUViwR9 h9tLANCqnGvEVMMialNn+zIBS2/ihRKeMJcOo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=niLX3fP+qb29CZcYqzjJsKB8IPoHuBgk/o2Wh/Novak=; b=iJK6ZEIdEgVWozB0wBzsgIqhALsMxureLaCBuAKQ5QW25irZaB4vMt15HO9//wlcZN tl9OpsHSj6+KGPHkeh6j08V0LJXQ6NLhIDFVFkxcDr2KSWB6MaRYARY5JGAbox0uNrEu mJ86c2529XZM8t7eimcHYgWMCO2X17pSrLzr6IvE/gTfOmrR+4I5qJkqv1QrsbiSG04L 2dCwg94S6LuYlOTMqVXjnW83watKXYifSze8M1UB0D53lIHRXrQQVMC76rsfjG+k2ZC6 F4GsNYmWvI68GktBDW9Bw42chjOmpKrnZlf8Fhi4MNryBtv8tU2SypaJfSbeT3LWUIVU 2ilw==
X-Gm-Message-State: AGi0PuaYx8mz9+f4K5PWXGw9pdAkgsSbrPXjaqYNCHDsI/GbJsF3OF86 ZHvJXPew3uqbawTuh0/dfGiHSA==
X-Google-Smtp-Source: APiQypKMcpj48FxPXN26SzbxZHxORkKXh8RcKw85lqtjJBo2bLDs4XUaTwvhuo4e+n8nB/CE0KtXqQ==
X-Received: by 2002:a37:d93:: with SMTP id 141mr6822541qkn.32.1587692241346; Thu, 23 Apr 2020 18:37:21 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:350b:c4cc:d0d7:363b:8799? ([2607:f2c0:e784:350b:c4cc:d0d7:363b:8799]) by with ESMTPSA id m33sm120834qte.17.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2020 18:37:20 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_792B7E38-E202-47FB-BE28-2D05AF20B8AE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 23 Apr 2020 21:37:17 -0400
In-Reply-To: <>
Cc: dnsop <>, dnsop-chairs <>
To: Tim Wicinski <>
References: <>
X-Mailer: Apple Mail (2.3608.
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: Fri, 24 Apr 2020 01:37:31 -0000

On 20 Apr 2020, at 14:03, Tim Wicinski <> wrote:

> This starts a Call for Adoption for draft-pwouters-powerbind
> The draft is available here: <>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

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

I identify with Warren's furrowed brow as he asked how this draft would protect against a rogue registrar or registry publishing a zone with a covertly-modified delegation, since such rogue behaviour would not be identified or suppressed by the mechanism proposed in this draft. This seems fundamental to the concept of "delegation-only" which is the central and sole consideration of this proposal.

Perhaps more substantially, but with more rapid oscillation of hands, I am concerned that this draft, if adopted, will gain legitimacy in policy circles where it might actually do damage. An example might be where there is contractual or market pressure to require it for TLDs where its effect might be to cause suppressed orphan glue to break otherwise functional delegations. It seems better to me to understand the implications of the mechanism up front before it gets close to an RFC number, because those RFC numbers can smell deceptively potent.

I would prefer this idea to be better fleshed out in these areas before the draft sees adoption, and hence I do not support adoption at this time. I understand the sentiment expressed by some others with the opinion that the proposal in any case does no harm since it's optional, but I find myself less optimistic about the future than they are.

My day job is at a company responsible for a significant and venerable top-level domain. Lest anybody infer otherwise, let me confirm that we are very much in favour of measures that allow compliance to be ensured through automated and mechanical means and, correspondingly, for trust in our stewardship to be as close as possible to absolute. I am, in general, very open to ideas that would promote those things. However, I am not convinced that this proposal will get us there and I am concerned that the legitimacy that is associated with the work on this group might ultimately result in collateral damage.