Re: [DNSOP] On Powerbind

Ben Schwartz <bemasc@google.com> Tue, 14 April 2020 23:35 UTC

Return-Path: <bemasc@google.com>
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 274C33A128F for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 16:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 ooIQp2gAm1mE for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 16:34:59 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4CB3A128E for <dnsop@ietf.org>; Tue, 14 Apr 2020 16:34:58 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id t14so3442307wrw.12 for <dnsop@ietf.org>; Tue, 14 Apr 2020 16:34:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YnRHxkLChPhORiW/JMvbyFTBS83vAX668f5GJUuS6QA=; b=nx7BKEluPbBchtAItrVClMMvnZ73BJHTNtSU+4Uc79MOcb324tRxAxMFILYsKZ5ZiL ZXrN4RZe6bMANaqhz5DL1EuwHSzIr/T1knZaeDi+bgXb+1bC1jItIJo8mbqZXA06sUGO kIBali+q/UZT5/nB1UgemRQWe3NvecVQyM0WaNXEPSVJ9mwhKD4NjW05/dYxtE3/tJo6 tMoZFnP71B9kpIiGO6pugSlCGTSieiv/eNaz/W5MBHNyZieR90frcp0Wk0da1343OSTX AvW2ihVNN2B0nFPGwufQYeVxVmBakPBiESeVhE9JSSV0Vbvl9mDpU/Bqw7JxDHkIyZl/ iYnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YnRHxkLChPhORiW/JMvbyFTBS83vAX668f5GJUuS6QA=; b=TuYelmI1Y9Z3MVqFqFymLeL6PWoKySE9e0wkd+/4+jJ1MuR3iQ7AgGnNNSCfljOVpB 5vxrCm+6NleE1TTASQEKkxh/oBB1dcjxq/P/3F/SJZSWOuKbBG6KfM26MwNgenwKtvDF +SA2lw0gmshmG8/yG1Mq9o2qL/PBniBuFoE8fGA9jUnnMa732yrtf6Frx2NTWUMVqEOX qu7swPcTVA+93OLgB+IrH2JgehZRMCXD2PaC8dhKyQPo9N4yGY5vIKs16AOr2NN0AsCc 1ACZNjgsZ4padpHPKmq1lIGhdZm5lCSqHW0qCxiajZC9cNzZtezCTLVxFhEYClQJ6F0l +3FA==
X-Gm-Message-State: AGi0PuZvZkLia4NJNiqQFLdsajOP2AknjCBw4C3xmUgMZvgqScwlan3l ulsmC56G6xtPra1qD6FePEFai29Wg/CFhaIa2xP+AbTk
X-Google-Smtp-Source: APiQypLI8e6B/Jouuajqz4PD7WcAqHoZc0NaVhnAHNBwhILzrnKlmrI1k2bSoZhFbwJGG2sTDcg+fuL9BoUVXIjM9rE=
X-Received: by 2002:a5d:610e:: with SMTP id v14mr17094817wrt.159.1586907296895; Tue, 14 Apr 2020 16:34:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com> <ybllfmxvhlr.fsf@w7.hardakers.net>
In-Reply-To: <ybllfmxvhlr.fsf@w7.hardakers.net>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 14 Apr 2020 19:34:45 -0400
Message-ID: <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000c3033605a348a599"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hsfJFoDCPqu6xVh9xdGYWDmuHLk>
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 23:35:02 -0000

On Tue, Apr 14, 2020, 6:16 PM Wes Hardaker <wjhns1@hardakers.net> wrote:

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


I'm still not able to understand this.  Suppose nic.footld puts a statement
for humans on their website that says ".footld promises to be
delegation-only".  Then a log operator and its contributors can simply log
everything signed by .footld's key, which should only be delegations.  If
anything other than a delegation shows up in the log, that is an obvious
breach of the commitment.  If a customer of .footld sees a delegation in
the log that doesn't match their DNSKEY, they can raise a stink.

This is without Powerbind.  How does Powerbind make this better?

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

This seems like it can easily be communicated just to humans, manually
enabling logging for each zone of interest.  Since only the TLDs and
similar zones are really of any interest for logging, manually maintaining
a list of zones to log is not difficult.  Certificate Transparency
operators similarly maintain lists of approved CAs whose certificates are
permitted in their log.  A curated list of this kind is required
regardless; otherwise a hostile or buggy zone could spam the log with
records.

I still don't see why we need a machine-readable label to tell the logs
that a zone is delegation-only, but if we do need one, we can have it
without changing the behavior of recursive resolvers, and without needing
to place anything in the parent (i.e. root) zone.

What am I missing?

-- 
> Wes Hardaker
> USC/ISI
>