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: Brian Wellington <[email-masked]>
Date: Fri, 28 Feb 2003 15:22:54 -0800 (PST)

> insecure DNS, this prohibition seems ill-advised.

I'm not sure where negative caching fits into this.  The RRsets returned 
as part of a valid negative response should all be verified; there's 
nothing in the negative reponse which would be classified as anything 
other than Authenticated.

> Should we remove this prohibition?

As the prohibition is dictating implementation details, it probably should 
be removed.  It's reasonable to suggest this behavior, but the only thing 
that should be enforced is that clients don't see bad data (clients should 
possibly get bad data if they issue a query with CD, but I don't care too 
much either way).

Brian

---

From: Rob Austein <[email-masked]>
Date: Fri, 28 Feb 2003 19:28:42 -0500

> other than Authenticated.

You're thinking of conventional negative response caching, for which
you are of course correct.

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.

---

From: Greg Hudson <[email-masked]>
Date: 28 Feb 2003 21:23:30 -0500

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

---

From: Brian Wellington <[email-masked]>
Date: Fri, 28 Feb 2003 18:56:17 -0800 (PST)

> doing so, hence the question.

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.

Brian

---

From: Rob Austein <[email-masked]>
Date: Fri, 28 Feb 2003 23:23:12 -0500

I'm not really trying to have a debate here, the point was to ask the
WG a question.  However, since Greg's comments suggest that the
context of the question may have been unclear, one clarification:

At 28 Feb 2003 21:23:30 -0500, Greg Hudson wrote:
> ...
> 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.

The text I'm asking about forbids the security-aware resolver itself
from caching "Bad" data, regardless of what it's going to do with that
data or whether it's ever going to send that data anywhere.

What data a security-aware recursive name server is allowed to send to
to a resolver is a separate matter, addressed elsewhere.  As far as I
know, nobody's suggesting that a security-aware recursive name server
should send "Bad" data a response except perhaps when responding to a
query with the CD bit turned on.  Different issue.