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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
