Subject: Re: Protecting caches?

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 01 Sep 2008 11:08:54 +0200

Paul Hoffman wrote:
> At 1:08 PM -0400 8/27/08, Andrew Sullivan wrote:
>> What I haven't seen much of is discussion of protecting caches _as
>> such_.  That is, given that we are going to cache, are there
>> techniques that solve the dangers of a cache other than just
>> preventing the cache from ever having the wrong data in the first
>> place?
> 
> What I have not seen, even post-Kaminsky, is a good discussion of what
> we put into a cache. For example, I am still befuddled about why part of
> the Kaminsky attack works. If I have a record in my cache with days left
> on the TTL, why should an attacker be able to change that record with
> bad information when I'm asking about a different record? The advantage
> of this ("we gave too long of a TTL and now need to move the IP address
> quickly") seems to be heavily outweighed by the ease of the attack.

Well I sent in a draft (resolver-side-mitigation on
http://tools.ietf.org/wg/dnsext ), that tries to solve the 'what to put
in the cache' problem.  So that, even if the transaction poison attempts
are successful, the cache is not poisoned.

It describes a method to perform lookups for NS and nameserver address
data.  Basically priming queries for every nameserver.  It does not stop
 resolution if the nameserver does not respond to the priming query
(i.e. broken servers), but I hope that very many servers do respond.  In
that respect I hope that the ability of servers to respond to priming
queries is much like the 0x20-support that exists today.

I am interested in discussing the trade off here.  Like Paul and Jinmei.
 This proposal makes up 70-90% extra DNS queries.  Also, it keeps the NS
and nameserver address data in the cache until TTL expiry, stopping the
promiscuous provision of newer data in other queries.

The proposal mixes well with DNSSEC, as it turns out, since if you
enable validation for the queries (you get more queries to create the
chain of trust, and larger ones), then the recursor gains some ability
to detect misdirections.

As far as I know, the methods described in my draft stop the different
ways that the cache is being overwritten.  Apart from Nicholas's
webpage-yahoo-iframe attack, but that one does not work by exploiting
cache rules, and is much closer to a MitM attack.

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Peter Koch <[email-masked]>
Date: Mon, 15 Sep 2008 10:30:22 +0200

On Fri, Aug 29, 2008 at 01:17:58PM -0700, Paul Hoffman wrote:

> Or that it should be reconsidered in the current light. A small 
> modification to the text might go a long way. For example, it says:
> 
>    Unauthenticated RRs received and cached from the least trustworthy of
>    those groupings, that is data from the additional data section, and
>    data from the authority section of a non-authoritative answer, should
>    not be cached in such a way that they would ever be returned as
>    answers to a received query.  They may be returned as additional
>    information where appropriate.  Ignoring this would allow the
>    trustworthiness of relatively untrustworthy data to be increased
>    without cause or excuse.
> 
> Adding "or glue from a primary zone" to the list in the first 
> sentence would eliminate the effects of the Kaminsky attack, would it 
> not?

Not sure I understand that fragment.  Once data has been put into the
additional section, you no longer know whether it originated from glue
records, from cache content or from data occasionally authoritatively
available at the responding server. Or are you suggesting not to use
glue RRs to fill the answer section?  That would aim at servers rather than
resolvers, then.

-Peter

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Sep 2008 08:00:35 -0700

>glue RRs to fill the answer section?  That would aim at servers rather than

I am proposing that information in the glue records that is not 
authenticated never be put in the cache of the recursive server.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Sep 2008 15:32:27 +0000

> authenticated never be put in the cache of the recursive server.

glue should never be promoted to answer.  if you received something
as glue you should follow it as glue or even forward it as glue, but if
someone asks you a question about it, you should pretend you don't have
it and go upstream.

i thought rfc 2181 had already clarified that point.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Sep 2008 09:46:15 +1000

> authenticated never be put in the cache of the recursive server.

	It's possible, I suppose, if one wants to re-delegate just
	about every delegation on the planet to all have glue less
	delegations.  Otherwise recursive servers need to use (which
	requires internal caching) the glue to get to the answers.

	It would make it possible to have all records signed by the
	parent when performing a referral.  The signatures on
	delegating NS RRset would be easy to identify as the signer
	would not match the owner of NS RRset.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Tue, 30 Sep 2008 10:18:30 +0200

* Florian Weimer:

> Here's an idea to contain the damage of a bad record by reducing the
> amplification effect (attack one cache, compromise the network view
> for thousands of clients):
>
> If information enters the cache for the first time, you only use it a
> fixed number of times before fetching it again from the network (say
> 10).  If the usage count is reached, you fetch the data from the
> network (even if the TTL has not yet expired).  If it is still the
> same, you double the counter.  If it is different, you fail back to
> the initial value.
>
> This will cause additional DNS traffic for those who publish unstable
> data.

After further consideration, this is mostly equivalent to the "double
up" approach (send all queries twice and compare the result).  The
main improvements are latency hiding, dealing with volatile data, and
(with a protocol change) signaling data volatility to upstream
servers.  This proposal requires caching of referrals, which current
implementations don't seem to do, adding quite a bit of overhead in
terms of cache size.  Compared to the "double up" approach, the number
of upstream queries is not significantly reduced.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Danny Mayer <[email-masked]>
Date: Wed, 01 Oct 2008 00:21:23 -0400

Andrew Sullivan wrote:
> No hat.
> 
> Dear colleagues,
> 
> In the discussion around forgery resilience so far, I've seen some
> discussion on how to detect cache poisoning attempts, and some
> discussion on how to foil the attack itself by reducing the ability of
> the attacker to send bad data to a resolver.  (I've also seen the
> observation, several times, that DNSSEC will solve these problems
> anyway, so we should concentrate on deploying that; that's an
> operational problem now, and not on-topic for this list.)

I don't altogether agree with this. DNSSEC will only protect up to the
resolver. What people keep forgetting about in this discussion is that
what you are really trying to protect is the application, most likely a
browser, from receiving bad answers, and therefore preventing the DNS
resolver from returning bad answers is not enough. The application is
one or two hops away from the resolving DNS. Some systems like Windows
uses a DNS cache to cache answers on top of everything else. As long as
getaddrinfo() and friends cannot request and receive a DNSSEC
"certified" response you are dropped right back to the original
problems. Worse than that, if you manage to poison the answers in the
resolver, you also poison the on-system cache AND the application. How
many applications request new answers once they have one? getaddrinfo()
and friends don't even tell you what the TTL on the answers you do get
so you have no way of deciding when to re-request an answer in the first
place even if the address was originally valid.

Danny