Subject: [DNSOP] Fwd: New Version Notification for draft-pwouters-powerbind-02.txt (fwd)

From: Paul Wouters <[email-masked]>
Date: Sun, 10 Mar 2019 23:41:30 -0400 (EDT)

Wes and I updated the powerbind draft.

We did a lot of rewriting to clarify the concept, so of you were confused,
please give this version another read. It clarifies a few issues based
on the responses we had so far, such as the limitations of RRTYPE's for
DELEGATION_ONLY zones (and how to deal with things like ns0.example.org
entries)

There were two ideas floating around we did not incorporate.

Any claims (or new bits to claim) parents aren't allowed to skip you is
one idea we did not add, as we couldn't find any behavioural change it
would cause, while causing a lot of politics :)

We also did not incorporate a new bit or bits to allow for variable
limits (eg to support things like co.uk)

We did add an exception for _label as those labels really only convey
information about the zone itself, and can never be mistaken for a
child delegation. This would prevent requiring zone cuts for all _label
directives (although it does not prevent these if you want to do them)

Note that it seems the datatracker broke and is throwing a 404 on the
below Htmlized page. Until that is fixed, you can read the document
on github as well: https://github.com/hardaker/draft-pwouters-powerbind/

Paul

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Mar 10, 2019 at 11:24 PM
Subject: New Version Notification for draft-pwouters-powerbind-02.txt
To: Paul Wouters <[email-masked]>, Wes Hardaker <[email-masked]>

A new version of I-D, draft-pwouters-powerbind-02.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Name:           draft-pwouters-powerbind
Revision:       02
Title:          The DELEGATION_ONLY DNSKEY flag
Document date:  2019-03-10
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-pwouters-powerbind-02.txt
Status:         https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
Htmlized:       https://tools.ietf.org/html/draft-pwouters-powerbind-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-powerbind
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pwouters-powerbind-02

Abstract:
   This document introduces a new DNSKEY flag called DELEGATION_ONLY
   that indicates that the particular zone will never sign zone data
   aside from records at the apex of the zone or delegation records for
   its children.  That is, every label (dot) underneath is considered a
   zone cut and must have its own (signed) delegation.  DNSSEC
   Validating Resolvers can use this bit to mark any data that violates
   the DELEGATION_ONLY policy as BOGUS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Mar 2019 08:30:22 +0000

Hi Paul,

On 10 Mar 2019, at 23:41, Paul Wouters <[email-masked]> wrote:

> please give this version another read.

I had not noticed the -01 revision of this draft, so apologies if any of my reactions below have already been discussed.

I think this -02 text is reasonably clear on the concept (at least, as I understand it), although some of the introductory text could be expanded a little to make the idea clearer. For example, section 3 begins with a broad statement that a superordinate zone can always override anything in a subordinate zone; I see what you mean by that, but it's really an observation of just the namespace and not about the structural separation of the namespace into zones (there is no subordinate zone if you remove the zone cut, for example, which is necessary for the condition being alluded to). By not mentioning the need to remove the zone cut I think it's possible that the reader would gain the impression that there is a wider vulnerability in the domain name system than the document actually describes, e.g. that a zone could be delegated and its contents still overridden by a the operator of a parent.

The draft introduces RFC2119 normative language, but then doesn't use any of it. The draft describes exclusions to the DELEGATION_ONLY policy that should presumably influence the behaviour of validating resolvers, but doesn't specify the required behaviour of validating resolvers with clear, normative language. Presumably the point of signalling the intended nature of the zone contents with a new parameter is intended to support some automatic enforcement of the intended zone policy?

The draft describes a problem but doesn't really consider it quantitatively. How much of this problem is theoretical, and how much has ever been observed to exist? There are functional barriers in place to make this a difficult attack vector (more difficult than stealing registrar credentials, for example), including the known machinery and protocols for large TLDs and the root zone not being trivially adaptable to the job of inserting arbitrary records into registry zones. Similarly, promotion of glue after the removal of a zone cut is a phenomenon that would be good to understand quantitatively, if a mechanism like this one would effectively suppress those promoted glue records. Before adding more moving parts to resolvers and to the registry handling of trust anchors as DS RRSets, it seems sensible to do at least a cursory cost:benefit analysis.

The operators of all (I would say, all) significant parent zones already wield significant control over their children since they control the delegation. This document describes a mechanism that in some sense is intended to keep the operators of parent zones honest, but really a dishonest operator of a parent zone can still cause damage to a child. In practice the operators of child zones have no real option but to trust their parents (or to choose a parent they feel comfortable trusting, in the case where there is a choice). The parent zone operators we ought to care most about are arguably TLD operators, which tend to either promote trust through things like their observed and consistent good behaviour in a community or their responsibility to members or shareholders under the law, since usually bad behaviour of the kind imagined here would be at odds with their business models. This mechanism attempts to address one possible mechanism by which a parent zone operator could do bad things, but there are other mechanisms and it's not obvious that the parents we care most about have any clear motivation to act badly. Perhaps I'm wrong that keeping TLD operators honest is the intention? There could certainly be other parent zones that don't fit the pattern above, but it's not obvious to me what they are. Perhaps the draft could explore that in more depth.

The document recommends that the described mechanism be implemented immediately in the root zone, in effect requiring a key roll. This seems like an expensive operation to recommend without presenting a *really* convincing argument that there are real-world problems to solve. Also, the IETF is kind of has the responsibility for technical policy in the root zone, a bit, maybe, and there's an administrative cost in appearing to exert it. That shouldn't be done lightly, either.

There has been discussion in the past of removing the zone cut between the root zone and the root-servers.net <http://root-servers.net/> zone. RSSAC028 didn't recommend such a change and I'm not suggesting it's likely to happen or has any practical advantages, but if the root zone was declared to be delegation only using this kind of mechanism it would effectively put an end to the possibility of such a change. I wonder whether that's sensible, especially since (as the draft mentions) the contents of the root zone are especially public and of a size that is easy to audit using other means.

Some zone parents construct their own DS RRSets on behalf of their children (children send a DNSKEY, not a DS RRSet; the parent generates a DS RRSet for them). I haven't thought about this enough but I have a niggling feeling that a new DNSKEY option would require changes in registry systems and potentially in EPP as well as in the DNS in order to accommodate the new flag.

It's good that the other, earlier use of the phrase "delegation only" is mentioned in the document, but I think that since the intended meanings are somewhat different and since the use in this document doesn't actually mean delegation only in a pedantic sense (as described, it's delegation only except for when it isn't) it might be clearer to invent a new phrase. Perhaps "registry zone" is closer to what is intended.

Joe