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

From: Rob Austein <[email-masked]>
Date: Fri, 28 Feb 2003 15:16:06 -0500

Q: Is a security-aware resolver allowed to cache RRsets for which one
   or more SIG RRs exist but none of them validate?

Discussion:

Excerpt from RFC 2535, section 6:

   Data stored at a security aware server needs to be internally
   categorized as Authenticated, Pending, or Insecure. There is also a
   fourth transient state of Bad which indicates that all SIG checks
   have explicitly failed on the data. Such Bad data is not retained at
   a security aware server.

This appears to rule out any form of caching for RRsets with
signatures which do not validate, including any form of negative
caching.  Given the demonstrated need for negative response caching in
insecure DNS, this prohibition seems ill-advised.

Please also note that this appears to be dictating implementation
details than just describing externally visible behavior, and that the
RFC 2535 rule may require a security-aware recursive name server to
leave itself open to denial of CPU-time attacks by requiring the
server to repeat the same signature checks over and over again.

Should we remove this prohibition?

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