Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

[Shane Kerr <[e-mail]>]

Joe,

On Fri, 16 Oct 2015 15:06:50 -0400
"Joe Abley" <[e-mail]> wrote:

> On 16 Oct 2015, at 14:42, Shane Kerr wrote:
> 
> > Seems like quite an easy attack at first blush. One could send a
> > constant stream of priming answers to resolvers since they would get
> > made once a day.
> 
> The successful attacks like this that I've seen rely upon being able to 
> trigger a particular query from a resolver so that you can bombard it 
> with responses in the hope of matching a query id. If there's no viable 
> trigger (unless you can exploit a software defect and trigger a restart) 
> the attack seems harder.
> 
> > While the chance of poisoning any one resolver with such a response is
> > low, the impact is catastrophic to a non-validating resolver, as an
> > attacker basically owns your view of the Internet at that point. For
> > resolvers that do validate, the only issue is information leakage that
> > a random party can see all of your root queries (or possibly a DoS).
> 
> Agreed, that the impact could be high if an attack is successful. My 
> questions are principally about the probability of success, I guess.

Yes, that's the question. :)

I think it depends on whether an attacker is interested in attacking a
specific resolver or whether they are content to fish.

You can't trigger the query, but you know for certain the exact query
that will be made 1x per day by almost every recursive resolver on the
Internet. Given that there are reportedly 20 million *open* resolvers on
the Internet, the chance of being able to exploit *some* resolver based
on priming queries seems actually pretty good.
 
> >> We're talking principally about a risk to resolvers that prime but 
> >> don't
> >> validate, right?
> >
> > This draft also says that you MUST NOT set the DO bit on priming
> > queries, so any resolver following this draft isn't validating.
> >
> > While a resolver could validate the NS RRSET, as you know the
> > ROOT-SERVERS.NET domain is not signed, so the A and AAAA records
> > (what you really care about) cannot be validated.
> 
> Right, and I think that's only a big problem for validators if the
> key assets you are relying upon (the answers that end users are using
> the DNS to fetch) are for qnames like L.ROOT-SERVERS.NET, which
> outside operational troubleshooting seems unlikely to be true.
> 
> An end-user looking for answers about ISC.ORG or PAYPAL.COM are going
> to be protected so long as there are signatures all the way down to
> those zones, regardless of what junk they receive from their priming
> query. Protected from junk, that is, not protected from
> unavailability.

Good point. As I mentioned the risk to validating resolvers is just
information leakage (or DoS). But both of those could be avoided by
validating the priming query, so why not?
 
> > I know there is discussion about signing the root servers somehow,
> > so perhaps a resolver that cares could someday validate the priming
> > query... but we should probably remove the MUST NOT text around the
> > DO bit then, perhaps replacing it with a SHOULD recommending
> > validation.
> 
> The last time I did any thinking about this, presupposing widespread 
> DNSSEC deployment by zone maintainers and widespread validation,
> there was no obvious benefit to security to be found in signing the 
> ROOT-SERVERS.NET zone or RRSets returned in a priming response. There 
> was, however, the potential for greatly enlarged priming responses.

I really don't understand the phobia about enlarging priming responses.
It's practically another argument to use TCP for this so we don't have
to worry. ;)

> I appreciate that this draft says you MUST NOT set DO=1 on priming 
> queries, but the reality is that everybody does.

Which makes me think this should be changed.

Cheers,

--
Shane