Subject: [DNSOP] On Powerbind

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Apr 2020 12:07:54 -0400

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?

Thanks,
Ben Schwartz

P.S. Hostile zones can spam the log either way, so that problem is out of
scope.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Apr 2020 15:16:00 -0700

Ben Schwartz <bemasc=[email-masked]> 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.
> 
> 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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Apr 2020 19:34:45 -0400

On Tue, Apr 14, 2020, 6:16 PM Wes Hardaker <[email-masked]> wrote:

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

--

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Apr 2020 10:00:17 +1000

> On 15 Apr 2020, at 09:34, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> 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.
> 

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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Apr 2020 20:24:20 -0400 (EDT)

On Tue, 14 Apr 2020, Ben Schwartz wrote:

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

> 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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Apr 2020 00:30:00 +0000

a bit in the parent (DS RRset) to say this delegation point is itself 
delegation-only would be more interesting. perhaps a way to assure compliance 
with a contract, thus preventing any ambiguity along the lines of 
"sitefinder".

but a bit in the apex (DNSKEY RRset) is still interesting, as a declaration of 
intent, which is easily monitored to find out if that intent changes, and to 
allow widespread alarms if that intent isn't lived. one can imagine breakins 
at the registry or registrar which would have the power to insert new children 
but not the power to change the apex DNSKEY.

a mature system would explicitly support this kind of live second-set-of-eyes.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Apr 2020 10:39:01 +1000

The DS record doesn’t have a flag field.  If you want to add flags or otherwise
extend DS records it requires new DS algorithms that encode the flags/extensions
inside the digest field.  Its incrementally doable and has implications for all
future DS algorithms.  That said this proposal doesn’t include such a change.

> On 15 Apr 2020, at 10:30, Paul Vixie <[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Apr 2020 22:39:24 -0400

Thanks for the explanation, Paul.  Overall, I agree that Powerbind seems
low-risk, so I don't mind it being available for people who care about it.

The strongest argument I can think of for Powerbind is that it prevents a
certain class of accidental misconfigurations for delegation-only zones.

It also might enable a reduction in how much labor is required to maintain
a DNSSEC transparency system, by providing some partial automation.  This
requires some assumptions about DNSSEC transparency that are not yet
obvious.

On Tue, Apr 14, 2020 at 8:24 PM Paul Wouters <[email-masked]> wrote:

> > I'm still not able to understand this.  Suppose nic.footld puts a
> statement for humans on their website that says

I actually agree: PSL should live in the DNS, because it is entirely the
zone owner's decision whether they want PSL behavior.  However, DNSSEC
transparency logging _cannot_ be controlled by the DNS, because log
operators must decide for themselves which zones they are willing to log.
Otherwise they become arbitrary data storage systems for anyone in the
world.

Powerbind would allow a log operator to say "I will log any delegation-only
TLD".  I think any practical log will still need manual intervention to add
cases like .co.uk, and perhaps also to remove delegation-only TLDs that
nonetheless exhibit spammy behavior, but overall Powerbind still saves some
amount of labor in that case.  I tend to think that a log operator could
already just log everything in all the TLDs, delegation-only or not, but I
don't have the data to prove it.

> just a post-mortem that Certificate Transparency offers for the WebPKI.

I don't agree with this characterization.  A hostile or compromised TLD can
just as easily impersonate its children with Powerbind as without.

> these entities from misusing/abusing their TLD zone in the future.

As above, it would not.

> For
> example to do "sitefinder" type wildcard matching.

This is still possible with Powerbind, using online signing or NSEC3
opt-out.

> And this would get
> enabling logging for each zone of
> > interest.  Since only the TLDs and similar zones are really of any
> interest for logging, manually maintaining a

I definitely disagree.  Powerbind proves the existence of a zone cut, which
is not what membership in the Public Suffix List means.  It's perfectly
possible to need a zone cut in a place where you would not want PSL
behavior, and vice versa.

> > CAs whose certificates are permitted in their log.  A curated list of
> this kind is required regardless; otherwise
> own power.

Powerbind (without DNSSEC transparency) doesn't reduce the power of the
zone owner.  They can easily impersonate (or repudiate) their children
before and after.

> I'm grateful to Comodo and Google and Mozilla and others for
> that a zone is delegation-only, but if we
> or the USG.

In the absence of DNSSEC Transparency, someone who doesn't trust a TLD
before Powerbind has no additional reason to trust it afterward.  The TLD's
ability to make mischief is not reduced.

It only takes one bit and a dozen lines of validating resolver

---

From: Petr Špaček <[email-masked]>
Date: Wed, 15 Apr 2020 08:04:19 +0200

Hello everyone,

my impression from yesterday is that authors of Powerbind draft assume that everyone else has an idea how DNSSEC Transparency should be implemented, and this makes discussion much harder because IMHO this assumption does not hold.

Could authors elaborate on proposed DNSSEC Transparency mechanism, so we can get better idea what role Powerbind has? Do you refer to https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03 or some other document? Or are you talking about different idea?

Having said that, Powerbind *seems* to be useful and cheap addition, but at the moment I do not have enough information to be sure.

Petr Špaček  @  CZ.NIC

On 14. 04. 20 18:07, Ben Schwartz wrote:
> 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.
> 
> - 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?
> 
> Thanks,
> Ben Schwartz
> 
> P.S. Hostile zones can spam the log either way, so that problem is out of scope.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Apr 2020 09:27:41 +0200

On Tue, Apr 14, 2020 at 08:24:20PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 108 lines which said:

> > statement for humans on their website that says ".footld promises
> > to be delegation-only".
> 
> nic.<TLD>.

Not even ICANN TLDs :-)

https://nic.com/
https://nic.org/

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 16 Apr 2020 14:59:03 +0200 (CEST)

> Il 15/04/2020 02:24 Paul Wouters <[email-masked]> ha scritto:
> 

Personally, I do not have a strong opinion on this draft - if some people want it, why not. However I am a bit perplexed by this kind of motivation, as it seems misinformed on the current state of governance arrangements around the DNS. For example, the USG has been out of the loop for a while, though the .org quarrel has shown interesting ways in which the General Attorney of California can get back into it as long as ICANN is still incorporated there.

Also, I don't completely get why anyone would want to use a domain name in a TLD whose operator they distrust so much that they think that the operator could attack the zones it delegated. I see better value in the proposal as a way to counter potential attacks to delegated zones that could happen if the operator were ever compromised.

Anyway, I have a preemptive bikeshedding request: if this thing proceeds, please find another name that does not sound like a confusing portmanteau of two of the most widely used resolver implementations :-)

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Warren Kumari <[email-masked]>
Date: Thu, 16 Apr 2020 15:29:58 -0400

On Tue, Apr 14, 2020 at 10:39 PM Ben Schwartz
<bemasc=[email-masked]> wrote:
>
> Thanks for the explanation, Paul.  Overall, I agree that Powerbind seems low-risk, so I don't mind it being available for people who care about it.
<no-hats>
Just checking - the DNSKEY Flags field is 16 bits, and we have so far burned:
Bit 15 - SEP
Bit 7 - Zone key
Bit 8 - Revoked
Did I miss any (I wasn't able to find a registry for this)?

If not, we still have 13 bits left, and so using one for this seems ok
to me, especially if recursives doing something with it is optional...
(I had mistakenly remembered the Flags as being only 8 bits)
I'm still not convinced that DNSSEC Transparency will come to pass,
nor that many zones will use this flag, but I'm now much more sanguine
about giving it a bit...

W
</no-hats>

>
> The strongest argument I can think of for Powerbind is that it prevents a certain class of accidental misconfigurations for delegation-only zones.
>
> It also might enable a reduction in how much labor is required to maintain a DNSSEC transparency system, by providing some partial automation.  This requires some assumptions about DNSSEC transparency that are not yet obvious.
>
> I actually agree: PSL should live in the DNS, because it is entirely the zone owner's decision whether they want PSL behavior.  However, DNSSEC transparency logging _cannot_ be controlled by the DNS, because log operators must decide for themselves which zones they are willing to log.  Otherwise they become arbitrary data storage systems for anyone in the world.
>
> Powerbind would allow a log operator to say "I will log any delegation-only TLD".  I think any practical log will still need manual intervention to add cases like .co.uk, and perhaps also to remove delegation-only TLDs that nonetheless exhibit spammy behavior, but overall Powerbind still saves some amount of labor in that case.  I tend to think that a log operator could already just log everything in all the TLDs, delegation-only or not, but I don't have the data to prove it.
>
> I don't agree with this characterization.  A hostile or compromised TLD can just as easily impersonate its children with Powerbind as without.
>
> This is still possible with Powerbind, using online signing or NSEC3 opt-out.
>
>>
>> And this would get
> I definitely disagree.  Powerbind proves the existence of a zone cut, which is not what membership in the Public Suffix List means.  It's perfectly possible to need a zone cut in a place where you would not want PSL behavior, and vice versa.
>
> Powerbind (without DNSSEC transparency) doesn't reduce the power of the zone owner.  They can easily impersonate (or repudiate) their children before and after.
>
>>
> In the absence of DNSSEC Transparency, someone who doesn't trust a TLD before Powerbind has no additional reason to trust it afterward.  The TLD's ability to make mischief is not reduced.
>

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Dick Franks <[email-masked]>
Date: Thu, 16 Apr 2020 22:08:19 +0100

Warren,

Comments in line

On Thu, 16 Apr 2020 at 20:31, Warren Kumari <[email-masked]> wrote:
>8

> nor that many zones will use this flag, but I'm now much more sanguine

The lack(?) of a registry is indeed regrettable.

However, there seems to be some historical meaning attached to some of
the other flag bits.

If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can offer no coherent explanation:

    # The key must not be a NULL key.
    if (($keyrr->{"flags"} & hex("0xc000") ) == hex("0xc000") ){
        croak "\nCreating a DS record for a NULL key is illegal";
    }

    # Bit 0 must not be set.
    if (($keyrr->{"flags"}) & hex("0x8000")) {
        croak "\nCreating a DS record for a key with flag bit 0 set ".
            "to 0 is illegal";
    }

    # Bit 6 must be set to 0 bit 7 must be set to 1
    if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){
        croak "\nCreating a DS record for a key with flags 6 and 7 not set ".
            "0  and 1 respectively is illegal";
    }

which would seem to indicate that some of the other bits were thought
to have some meaning circa 2013.

Perhaps Olaf can shed some light on this topic.

Dick Franks
________________________

---

From: "Olaf Kolkman" <[email-masked]>
Date: Fri, 17 Apr 2020 11:27:05 +0200

Looking for this: 
https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ?

—Olaf

PS. Haven’t looked at this code for over a decade. That last croak, 
Postel principle violation?

> Perhaps Olaf can shed some light on this topic.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Olaf M. Kolkman                                     Tweets as: @kolkman
Principal - Internet Technology, Policy, and Advocacy
Internet Society                        https://www.internetsociety.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---

From: Dick Franks <[email-masked]>
Date: Fri, 17 Apr 2020 11:16:41 +0100

> https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ?
I guess we were.

The extraneous bits appear to be remnants of DNSKEY's previous life as a
KEY RR, defined in RFC2535 3.1.2, and presumably now obsolete.

Thanks Olaf.

--Dick