Hello, I'm going to generalize Ben's questions:
It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available. Please describe intended usage of the proposed mechanism, at the moment it is hard to see all the details and interactions. Petr Špaček @ CZ.NIC On 29. 07. 20 21:54, Ben Schwartz wrote: > I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to > make sure that the draft isn't overstating the achievable benefits. To that > end, I have some questions about the text of the -01 draft. > > (I recognize that these are issues I've raised before, but I still haven't > gotten answers that I understand.) > > Assuming the claims are correct, I think they need some clarifications for > naive readers like myself (and possibly deduplication, since some claims are > repeated in different sections). > >> Exposing such targeted attacks requires a transparency audit >> infrastructure similar to what is deployed for PKIX ([RFC6962]). >> However, a DNSSEC version would need to log significantly more data, >> as all signed DNS data used by a DNSKEY must be recorded in order to >> prove that data signed by a parent zone's DNSKEY was out of expected >> policy. The very distributed nature of the DNS combined with the >> typically frequent zone resigning rate makes such transparency logs >> prohibitively expensive and nearly impossible to operate. > > How does this draft alter that cost? For delegation-only zones that are in > compliance, it seems like the cost is not changed. Presumably violations > will be rare, so they won't contribute significantly to the cost. > >> Additionally, it would require zone owners to expose all their zone >> data to any public log operators, thereby introducing privacy >> implications and exposing all relevant DNS data to a public archive. > > I don't understand how this flag would alter that exposure. If my zone is > already delegation-only, how does adding this flag improve privacy? > >> At the time of this writing, the list of entries in the >> public suffix list contains over 8800 entries as well, with 73 wild- >> card entries (prefixed with a "*") indicating that all of their >> (unknown number of) children are public registration points. In the >> absence of an interoperable mechanism (like this draft provides), it >> is infeasible that a validating resolver or auditing log could know >> which of these zones are delegation-only without individual policy >> statements from each of them. > > Marking a zone delegation-only doesn't imply that it is suitable for logging, > so wouldn't participation in any logging scheme require an individual policy > statement anyway? > >> Finally, a DELEGATION_ONLY flagged DNSKEY for >> the root zone cannot be overridden easily, as it would require a >> trust anchor update in all validating resolvers. > > The preceding sentences deal with the lingering "false child key" problem, > which still applies here, so I don't understand the relevance of this > sentence. > > I also had some thoughts on the Security Considerations: > >> Care should be taken by resolvers to not >> unnecessarily empty their cache. This is specifically important for >> roaming clients that re-connect frequently to different wireless or >> mobile data networks. > > I believe this advice is counter to best practices for mobile clients for > both performance and privacy reasons. See e.g. http://dnscookie.com/. > > Also, I think it's worth mentioning that "delegation-only" zones can still > deny the existence of a DS for the child (if the child was signed to begin > with), and then generate deep unsigned records for the child. This limits > the direct impact of this flag to cases where DNSSEC is mandatory. (Logging > might be able to deter this attack, assuming NSEC records are logged.) > > Thanks, > Ben Schwartz _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
