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

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Feb 2021 17:01:39 -0500 (EST)

On Wed, 29 Jul 2020, 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.

Whether or not they are in compliance does not alter the cost. Once the
delegation-only bit it set, only the DS/DNSKEY records need to be logged
instead of all data signed with the parental key. Any "deep signed"
data by the parental key will be rejected automatically by resolvers
supporting this, so there is no requirement to log these.

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. Attackers could also try to hide and
seek via CNAMEs. All of these would need to get logged. Versus only
logging DS/DNSKEY.

> >   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?

I have removed this section, as with our current DNS model, all queries
are seen anyway by some people (like Paul Vixie et all)

> >   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?

DNS audit logs could decide to only log parents that are
delegation-only. To protect themselves and to advocate for
parents adding this extra transparency / security to their zone.

> >   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 agree. I removed the 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/.

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? So you would become less
trackable?

> 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.)

Any zones under the (signed) parent that are not signed are completely
untrustworthy anyway. We cannot help these zones. Any of their data
can be spoofed by anyone in the forwarding chain.

A rogue parent changing or modifying the DS set cannot be prevented,
but can only be logged. When we mention DS logging, that includes
the logging of the absence of a DS record. So that includes any
switching of the zone from secure <-> insecure.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Feb 2021 17:09:09 -0500 (EST)

On Thu, 30 Jul 2020, Petr Špaček wrote:

> 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.

I think the draft clearly explains that without delegation-only, a
parent can just present any record of the child zone from within
its parent zone, as if there was no delegation. Even if there is
one. That is, it can still serve DS records, but also service
TLSA records past its zone cut. So if a resolver asks the .ca
nameservers for _443._tcp.nohats.ca IN TLSA, the .ca nameservers
could serve it while still also serving DS records for nohats.ca.

With this flag set, it can no longer do this and it must switch its
mechanism for overriding the child by modifing the DS for this child.

I think a concept of DNSSEC transparency where a DNS validator plugin
logs all different DS RRsets (and NSECs) from delegation-only zones and
uploads these once a day to a dnssec transparency monitor is a fairly
basic concept that I think this draft does not need to further expand.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Feb 2021 17:28:23 -0500 (EST)

On Thu, 30 Jul 2020, Joe Abley wrote:

>> This proposal is meant to increase the amount of trust people can place in
>> DNSSEC by decreasing the hard trust that is currently required of ICANN,
>> Verisign and the TLD operators. I understand in our community, we do
>> not see this as a big problem. Unfortunately outside our community it is.
>
> Can you provide some information about that? I think it would be helpful to understand the problem that people are bothered by.

The amount of times people quote Thomas Ptacek's article on this issue
is really high.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

It doesn't matter how much we debunk it and say this is an enigma
problem, or that ICANN or rootservers can be trusted and it is
just a conspiracy theory.

We can eliminate this entire discussion by setting 1 bit. It's easy and
cheap to do. And it signals good intensions by TLDs and ICANN/Root for
transparency in general. And might even prevent some governments from
cooercing TLDs because well, they won't be able to anymore.

>> It is further interesting that you raise your point of "the risk analysis
>> shows we can never afford to deploy this" when a few months ago you
>> raised the reverse point that "we dont want to be forced to have to use
>> this to be seen trustworthy". Both arguments cannot be true.
>
> Well, I didn't say that we can never afford to deploy anything. Clearly we can deploy lots of things all the time. I think I've explained why we couldn't just turn this on in ORG right now, and so a requirement to do so would be a problem.

This is quote the more nuanced phrasing you use now. Now you are saying
that yes, with some changes to your infrastructure, you can support
this. Where as before you said "we can never ever support this". I
think that is good to have clarified.

> The lines of code to be added to particular implementations are not the only measure of complexity in deployment, however. We don't have a good handle on all the software that exists between application and authority server, nor how it interacts. There are costs in resolution failures that appear intermittent because they happen with some applications, networks or hosts but not others, assuming that it is deployed anywhere.

I don't understand this. Let's say example.org has:

example.org. IN NS ns1.deleted-domain.org.
ns1.deleted-domain.org. IN A a.b.c.d

Currently, .org would serve the 'glue' A record that it would sign. with the
.org ZSK.

You create a new zone, broken-nameservers.org, and you change the above to:

example.org IN NS ns1.deleted-domain.org.broken-nameservers.org.
ns1.deleted-domain.org.broken-nameservers.org. IN A a.b.c.d

You run and sign broken-nameservers.org. without the DELEGATION_ONLY flag.
The existing broken glue keeps working. And you even gain a new
indicator and could inform people on www.broken-nameservers.org that
their domain is in purgatory and they better start fixing it.

And now you can run your .org as DELEGATION_ONLY zone.

> If the technical difficulties for particular registries like ORG can be circumvented but the benefits are not obviously compelling, then there's the question of why any commercial registry would implement this proposal. If it needs to happen as a contractual obligation, then that means contract changes and although that's very much not my area, my sense is that that's a fairly heavy ball that needs to be rolled up a steep and tall hill. That sounds like a cost to me.
>
> Without widespread implementation, I'm not sure how the problems (admittedly, problems that I don't really understand) will actually be addressed. The costs will remain, however. And right now I haven't heard a single example of a TLD that might be in a position to implement this (not saying there isn't one, just that I haven't heard an example).

I think this argument is the same as for IPv6, DNSSEC, and many other
new protocols. It's like saying there is no reason to add signaling to
wifi hotspots because no one will implement it because they have some
interception method that works now. Still, we are trying to improve the
protocols there too so we can at some point in the future enhance and
improve those protocols. Maybe for .org that will only be after the
market pressure that you explained you feared earlier in this
discussion. To me, that would be a success of IETF increasing the
trust in DNSSEC - even if we ourselves believe root servers or TLD
servers would never be coerced into a position of provding maliciously
signed data to third parties.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Feb 2021 10:30:38 -0500

Thanks for these replies, and updates, Paul.

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

> signed data is legitimate or not. That is what the delegation-only flag
...

> 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?
>
> 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 believe this advice is counter to best practices for mobile clients
> for both performance and privacy reasons.  See e.g. http://dnscookie.com/.
>
> actually expire this dnscookie faster?

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

> So you would become less

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.