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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
