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

[Ben Schwartz <[e-mail]>]

Thanks for these replies, and updates, Paul.

On Sun, Feb 21, 2021 at 5:01 PM Paul Wouters <[e-mail]> wrote:
 ...

> It might be that the occurance of this deep signed data is rare, but
> without the delegation-only flag, you cannot determine if such deep
> signed data is legitimate or not. That is what the delegation-only flag
> indicates.
>
...

> > Presumably violations will be rare, so they won't contribute
> significantly to the cost.
>
> I don't know how rare this is, but for example if it became known that
> this logging was happening (due to not having delegation-only) then
> atttackers could spam the DNS transparency log with deep signed data
> that would have to be logged.


I'm not sure I agree.  For example, if a zone puts up a TXT record that
says "I promise to be delegation-only except in very unusual
circumstances", then a log could collect up to one deep RRSet (in addition
to all shallow DS and NSEC RRSets) for each child zone.  Any single
unexpected RRSet within a child zone is cause for concern for that child,
so there's really no need to log more than one RRSet per child for policy
enforcement.  That means the benefit to logs from DELEGATION_ONLY, as
opposed to "I am delegation only", is a factor O(1) _only for policy
violations_.  If the vast majority of the log is non-violating, the
difference in cost is a rounding error.  (If a large fraction of the
parent's log is violations, the log can impose a rate-limit and declare the
parent hopelessly violating.)

In other words, when the draft says:

> all signed DNS data signed by a DNSKEY must be recorded in order
> to prove that data signed by a parent zone's DNSKEY was out of
> expected policy.

This is not true for a delegation-only policy (or a nearly-delegation-only
policy), and that's the only policy that can be protected by the flag.

Attackers could also try to hide and
> seek via CNAMEs.


I don't see why it would be necessary to chase CNAMEs.  It should be enough
to log them, so the owner can be alerted that an unexpected record appeared
for their zone.

...

> > 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?
>
> DNS audit logs could decide to only log parents that are
> delegation-only.


They could, but they probably cannot simply log all zones that have the
flag.  It is trivial to spam the log from a delegation-only zone.  That
means log operators will still have to curate a list of zones to log (or
attempt to curate a list of zones _not_ to log, even as spammers move
around the namespace).

The reason I support this draft is because I think DELEGATION_ONLY
might work as a filter to identify logging-friendly zones when combined
with another pre-existing curated list, such as the TLDs or the PSL.
However, given the difficulty of making many TLDs purely delegation-only, I
think we might do better to define a flag that is used only by the log
operator.


> > 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/.
>
> I read up on that page but the information there is not very detailed. I
> _think_ that forgetting a cached entry before its TTL is up, would
> actually expire this dnscookie faster?


Yes, but the security considerations say _not_ to empty your cache.


> So you would become less
> trackable?
>

FWIW, I think the best practice is really to partition the DNS cache by
network interface.  That's not quite the same thing as "emptying" the cache
when switching between networks.  In principle, one could cross-check DS
records across cache partitions, even if the other cached records aren't
being used.

More broadly, I don't understand what a resolver is supposed to do on the
basis of records it has in cache, in order to detect an attack.  It seems
like more caching of DS records is just as likely to benefit the attacker,
since the false DS records can be cached just as well as the real ones.
Maybe this could be explained in more detail.