Subject: Re: Q-6: May security-aware resolvers cache "Bad" data?

From: Sam Weiler <[email-masked]>
Date: Thu, 27 Mar 2003 02:38:30 -0500 (EST)

On Wed, 5 Mar 2003, Edward Lewis wrote:

> Pro removal: the crypto equivalent of neg caching is possible.
> OTOH:        an attack of sending bad SIG's can "starve" a cache
> Pro removal: local policy can be to return data only if the cd bit is set
>               (i.e., saves cache from requerying itself on repeated queries)
> OTOH:        not caching it makes the requester try to get it from source
>               (i.e., will return it anyway on +cd, but won't remember)

I can imagine a chronically-broken delegation for which many
validators/clients hard-configure a key.  If a cache that knows
nothing of the zone's real key is sitting in front of a bunch of those
clients, should it cache the data?

Ed might be on to something: you return cached data only with +cd set.

Even so, I'm thinking Brian has the right security analysis:

> While forbidding failure caching might be going a bit far, caching
> failures is really not a good idea.  It means that if a server receives
> a spoofed response, it will cache the data, and use the cached failure
> as an  indication to not try again.  This leads to obvious DoS attacks.

Given the security model, though, it's sort of a toss-up -- you're
only guaranteed to be able to identify bad answers, there's no
guarantee that you'll get the good one.  And you don't want zones
getting beaten to death when their secure delegation breaks, so
perhaps caching is really a good idea.

Maybe it should be left to the implementation.

-- Sam

--
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: Paul Vixie <[email-masked]>
Date: Thu, 27 Mar 2003 14:09:11 +0000

>               (i.e., will return it anyway on +cd, but won't remember)

negative caching functions as a "hold-down", which on the one hand helps
with authority-server and network load as well as average completion time
for queries which will fail due to broken validation chains, but on the
other hand means that a broken chain that is repaired will not be visible
during the negative caching window.

for name nonexistence we tolerate the hold-down because the chance that a
name doesn't exist due to an error is thought to be low compared to the
chance that it really doesn't exist.

for validation failure i think we can make the same assumption.  broken
validation chains are errors, not omissions, and if the minimum retry
interval before trying to validate it again is, say, five minutes, then
it's more likely to help than hurt the zone owner.

> Maybe it should be left to the implementation.

an implementation who didn't want to do negative caching should not be
considered incorrect by the specification.  so, the language could be
softened from "must not cache" to "may cache, with a negative TTL of up
to the zone minimum ttl, if the SOA was gathered securely, or five
minutes, whichever is shorter."

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Mar 2003 12:38:52 -0500

>Maybe it should be left to the implementation.

Yeah - less limitations. ;)

Really - since we don't know whether the hold down or the damping of 
traffic is better, let the implementors find out.

PS - Besides the potential for the middle box having the wrong key, 
it might also have the wrong time.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

---

From: Rob Austein <[email-masked]>
Date: Thu, 27 Mar 2003 13:18:54 -0500

> it might also have the wrong time.

That's the case that particularly concerned me.