Re: [DNSOP] On Powerbind

Paul Wouters <paul@nohats.ca> Wed, 15 April 2020 00:24 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 7FF013A1353 for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:24:28 -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 Nin0nxgN_SWq for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:24:26 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 EAF7A3A1350 for <dnsop@ietf.org>; Tue, 14 Apr 2020 17:24:25 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4923534MR0z734; Wed, 15 Apr 2020 02:24:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1586910263; bh=3gX0+DqVWEYgUn74a1dB58+Oq79Bi2857eWw32XP5xA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UT/WQq413LAJ04TgSmfiJowBL/4FYL0caVnsUpwi2qm7n4GeTikOs0AhFnG64AM2q WopH3/LuNUCCz9oMY2ocCKwnRjsvyLSnDXT2OtJXOUb5KAbNo7TiT5yNROovuPIP90 sAxL2l4TdgDxMiSkFzw/v1e7vULNUwu4ZqR5UecE=
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 an6slr8tcA0H; Wed, 15 Apr 2020 02:24:22 +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; Wed, 15 Apr 2020 02:24:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 093F1602980B; Tue, 14 Apr 2020 20:24:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0518D66B7C; Tue, 14 Apr 2020 20:24:21 -0400 (EDT)
Date: Tue, 14 Apr 2020 20:24:20 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: Wes Hardaker <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.2004141951540.5865@bofh.nohats.ca>
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com> <ybllfmxvhlr.fsf@w7.hardakers.net> <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hStogtWaI0YzP0zrFVZc9uv6Wr4>
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: Wed, 15 Apr 2020 00:24:29 -0000

On Tue, 14 Apr 2020, Ben Schwartz wrote:

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

First, this approach does not work. Not all TLD's have the ICANN mandated
nic.<TLD>. There is no standard on how to publish this information. There
is a chicken and egg problem getting to the website. You have to parse
this data. Get the mimetype right. Website outages would be problematic.
Website could be blocked to prevent reading the text. What is the expiry
date of this data? Look at the various security "web canaries" that have
been put up. They all fail to be maintained. And if anything Public Suffix
has shown us this kind of data cannot be tracked properly outside the
DNS. A few drafts have even attempted to pull in public suffix into some
DNS record type because of this. If there is no link between the statement
and the policy, they will diverge over time and cause false positives.

Second, with powerbind, you don't have to do a poor man's "after the
fact" protection. You can mark violating data as BOGUS and prevent it
from being accepted as valid before harm has been done. It's more than
just a post-mortem that Certificate Transparency offers for the WebPKI.

A third minor advantage is that setting this bit could become part of
the IANA/ICANN process for current and new gTLDs. It would then prevent
these entities from misusing/abusing their TLD zone in the future. For
example to do "sitefinder" type wildcard matching. And this would get
free enforcement via validating resolvers.

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

Public suffix has a simiar problem showing this process is error prone.
In fact, powerbind could obsolete this manually curated list, if all
public suffix parents would implement this bit.

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

Moving trust to a concortium of browser vendors and CAs is the opposite of
what we are trying to achieve here. We are trying to get to a scenario
where the owner of data can say what is and what is not allowed and
expected to happen, and to allow these owners to voluntarily reduce their
own power. I'm grateful to Comodo and Google and Mozilla and others for
CT, but we want to not have to trust them (or others) more than we need to.

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

DNSSEC Transparency is only one part of what powerbind allows you to do.
Enforcing reduced power/trust in keys in resolvers is the other part.

And we might disagree about the value of enforcment. But as I tried
to explain during the meeting, the value added is not for our little
community of engineers that trust each other. It is for people at large
to not need to trust some cabal and who do not trust ICANN, Verisign
or the USG. It only takes one bit and a dozen lines of validating resolver
code. And it is opt-in. In that sense it seems reasonable to let those
that see value in this use it. If people think there might be serious
operational risks, I would also be very interested to hear that. So
far, the only two items I know of are orphan glue and no longer being
able for TLD NS records to be entries within the zone itself. And I
do think these are managable - especially the orphaned glue is already
a lifeline given to failing child zones.

What I am interested in from a technical point of view is if we forgot
any technical issues or difficulties. Did we miss a use case? Can or
should we try to protect other records? Are we forgetting anything
related to wildcards, CNAMEs or DNAMEs ?

With that, I'm going to step back and let this discussion continue for
a bit without me replying to every message, as I think it is really
important to hear other people's viewpoints on this too.

Paul