Re: [DNSOP] On Powerbind

[Mark Andrews <[e-mail]>]

> On 15 Apr 2020, at 09:34, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> 
> 
> On Tue, Apr 14, 2020, 6:16 PM Wes Hardaker <[e-mail]> wrote:
> Ben Schwartz <bemasc=[e-mail]> 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?

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

The root zone doesn’t 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). 
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?
> 
> -- 
> Wes Hardaker
> USC/ISI
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]