[DNSOP] Questions on draft-ietf-dnsop-delegation-only

[Ben Schwartz <[e-mail]>]

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