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

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 3 Mar 2003 12:16:27 +0100

> 
> If that's what you mean, I'd suggest not using the term "negative 
> caching", which is well defined (the caching of a negative response,
> where negative means either the host or type doesn't exist).  I'd use a
> new term, like "failure caching".
> 
> 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. 
> Not caching failures has other problems (bandwidth amplification
> attacks), but the ability to spoof a server into caching failure is much
> worse.

Just one comment:

There are two reasons for failure: Crypto failure and Expiration. You
may want to treat them differently.

If you do failure caching (I am not quite convinced you want to) you
want to do that based on local policy and use TTLs that are
relatively short (order 10s of seconds).

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

--
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: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 08:12:21 -0500

There's one more case - an RRset for which a SIG RR should exist but 
the cache has none.  I.e., someone (ye olde cache?) stripped out the 
SIG's from the message.

At 15:16 -0500 2/28/03, Rob Austein wrote:
>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?

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 think removing the restriction places the power back into the hands 
of local policy, which is good, but am not sure if this makes the 
caches more or less "middle-boxy."

How about a requirement that a recursive server, in response to a 
query with the CD bit set to 1, returns the requested data regardless 
of local policy.  I.e., the recursive could answer from local 
(unverified) cache or could reissue a recursive query becuase it 
won't admit unverified data sets to the cache.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer