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

["Joe Abley" <[e-mail]>]

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.

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

> 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 appreciate that this draft says you MUST NOT set DO=1 on priming 
queries, but the reality is that everybody does.


Joe