Hi Paul, On 10 Mar 2019, at 23:41, Paul Wouters <p...@nohats.ca> wrote:
> 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. 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
