On Tue, Apr 14, 2020 at 10:39 PM Ben Schwartz <bemasc=40google....@dmarc.ietf.org> 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. > > On Tue, Apr 14, 2020 at 8:24 PM Paul Wouters <p...@nohats.ca> wrote: >> >> 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. > > > 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. > >> 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. > > > I don't agree with this characterization. A hostile or compromised TLD can > just as easily impersonate its children with Powerbind as without. > >> 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. > > > 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 >> 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. > > > 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. > >> > 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. > > > 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 >> 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. > > > 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 >> 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 -- 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
