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

[Greg Hudson <ghudson@MIT.EDU>]

On Fri, 2003-02-28 at 19:28, Rob Austein wrote:
> The reference here was to kind of negative caching for which we don't
> have a name yet, dealing with RRsets whose signatures are demonstrably
> bad, so that the resolver can avoid performing the same (failing)
> query and verification operations over and over again within a short
> period of time.  RFC 2535 appears to forbid this form of negative
> caching and doesn't discuss the (potentially serious) implications of
> doing so, hence the question.

Well, to the extent that the cache's behavior is visible to the querying
client, it's not an implementation detail.  It sounds like the text is
trying to prevent a security-aware caching server from providing bad
responses to a stub resolver, and that's important for people who want
to use security aware local caching recursive resolvers in concert with
old native stub resolvers.

If the caching resolver wants to cache the bad response (or a hash of
it) in order to avoid redoing expensive cryptography operations, that's
obviously an implementation detail and is fine.  Thunking is always okay
when timing attacks aren't an issue.

If the caching resolver wants to cache the fact that it got a bad
response last time so it doesn't have to bother again, that has a couple
of problems: we don't know how long to cache for (any information in the
bad response has to be discarded as potentially malicious, and there's
no SOA record there anyway), and it could make DOS attacks easier. 
There may be some scaling issues associated with doing no caching of
this sort, but I don't think they're the kind of issues that can be
solved during an editing pass.


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