Re: [DNSOP] On Powerbind

Wes Hardaker <wjhns1@hardakers.net> Tue, 14 April 2020 22:16 UTC

Return-Path: <wjhns1@hardakers.net>
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 551E43A115A for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 15:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 QNG5UrKpAnPs for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 15:16:01 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FAF3A113F for <dnsop@ietf.org>; Tue, 14 Apr 2020 15:16:01 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 7AB5A2F2EE; Tue, 14 Apr 2020 15:16:00 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com>
Date: Tue, 14 Apr 2020 15:16:00 -0700
In-Reply-To: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com> (Ben Schwartz's message of "Tue, 14 Apr 2020 12:07:54 -0400")
Message-ID: <ybllfmxvhlr.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1j6xNJwY7dWUQLI_JhNF7CJw8AI>
Subject: Re: [DNSOP] On 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, 14 Apr 2020 22:16:06 -0000

Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> writes:

> If I understand correctly, the Powerbind draft is designed to reduce
> the amount of data that must be logged in order to verify appropriate
> use of a DNSKEY "K" for a delegation-only zone.  I'm trying to compare
> the amount of logging required with and without Powerbind.
> 
> Here's my current best guess:
> - With Powerbind, we need to log all DS records (to detect replacement) and
> NSEC and NSEC3 records (to detect repudiation) that are signed by K, along with
> their RRSIGs.  Resolvers would reject any other records signed by K.
> - Without Powerbind, we need to log any record signed by K that is not on the
> apex, along with its RRSIG.
> 
> But for a delegation-only zone, aren't these the same set?  What else would a
> delegation-only zone be signing beyond the apex, other than DS, NSEC, and
> NSEC3?

The point of powerbind is to specifically state "I'm delegation only".
Without knowledge of that, you end up having to log everything, per your
own conclusion, because there is no way to know if its a delegation-only
zone.  As the first sentence in the abstract says "This document
introduces a new DNSKEY flag called DELEGATION_ONLY that indicates that
the particular zone will never sign zone data across a label.".  IE, the
whole point is to communicate that a zone is such a zone.

-- 
Wes Hardaker
USC/ISI