Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com>
Date: Wed, 15 Apr 2020 10:00:17 +1000
Cc: Wes Hardaker <wjhns1@hardakers.net>,
 dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E521F8C-8628-40C1-95AA-9E84D5B9C7C5@isc.org>
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com>
 <ybllfmxvhlr.fsf@w7.hardakers.net>
 <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/g1XEEdqkfQrqS-duiqipHQ-MlUo>
Subject: Re: [DNSOP] On Powerbind
Precedence: list



> On 15 Apr 2020, at 09:34, Ben Schwartz =
<bemasc=3D40google.com@dmarc.ietf.org> wrote:
>=20
>=20
>=20
> On Tue, Apr 14, 2020, 6:16 PM Wes Hardaker <wjhns1@hardakers.net> =
wrote:
> Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> writes:
>=20
> > 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.
> >=20
> > 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.
> >=20
> > 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?
>=20
> 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. =20
>=20
> 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.
>=20
> This is without Powerbind.  How does Powerbind make this better?

You can effectively have every validating resolver on the planet =
enforcing that responses meet
this policy by default with 2-3 years.  Today the majority of responses =
from authoritative servers
are processed by 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.
>=20
> 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.
>=20
> 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.

The root zone doesn=E2=80=99t have anything new unless it decides it =
wants to declare that it
is delegation only (which I think we should request that IANA does for =
the Internet).=20
For a TLD to declare it is delegation only it only needs to perform a =
DNSKEY roll to
a DNSKEY RRset with this bit set.  As part of the DNSKEY roll a new DS =
record is published.
TLDs do DNSKEY rolls all the time and push new DS records to the root =
all the time.  There
is no process change in the interactions between IANA and the TLDs for =
this to happen.

> What am I missing?
>=20
> --=20
> Wes Hardaker
> USC/ISI
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org