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

[Sam Weiler <weiler@tislabs.com>]

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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>