On Wed, Aug 27, 2008 at 06:54:53PM -0400, Dean Anderson wrote: > I suggest you review the past emails and the RFC's to find out what is > meant by a 'non-verifying DNSSEC cache'.
I have a passing familiarity with the RFCs, and the phrase "non-verifying DNSSEC cache", and even "non-verifying", appears nowhere in RFC 4033, RFC 4034, or RFC 4035, as near as I or grep can tell. I think you have some terms confused, which is why I asked. In particular, > A DNSSEC-aware cache need not verify the responses it caches. I think that the word you want here is "validate", not "verify". The terminology is defined in RFC 4033 in particular. There are places in the documents where other terms -- "authenticate" is also used -- turn up, but for the purposes of this discussion, I think it's best that we stick to the strictly defined terms so that we don't get confused. Usually, I think it preferable to say that individual signatures are verified, and responses are validated. There is a subtle difference between these two notions, and understanding the difference is going to be crucial in evaluating some of the claims you are making. This is why I'm trying to be precise. So let me outline the cases I think there are, and you can say whether I've captured all the cases you think are relevant, and where you think the vulnerabilities are. In each case, let's assume we are asking for a name that has been signed so that we don't have to worry about cases that we know can't be secured. Case 0: security-oblivious stub resolver, security-oblivious recursive resolver, security-oblivious server. [Note: this case is effectively impossible under our assumption, since the server can't really serve a domain that's been signed. I have it here for completeness, but a deployment like this is already broken in operation. I'll skip cataloguing the other variants of "security-oblivious server" on these grounds.] Case 1: security-oblivious stub resolver, security-oblivious recursive resolver, security-aware server. Case 2: security-oblivious stub resolver, security-aware recursive resolver with a local policy of "no DNSSEC", security-aware server. Case 3: security-oblivious stub resolver, security-aware recursive resolver with a local policy of "DNSSEC", security-aware server. Case 4: security-aware stub resolver that does not set the CD bit, security-aware recursive resolver, security-aware server. Case 5: security-aware stub resolver that does set the CD bit. security-aware recursive resolver, security-aware server. Case 6: security-aware stub resolver that does not set the CD bit, security-oblivious recursive resolver, security-aware server. Case 7: security-aware stub resolver that does set the CD bit, security-obvlious recursive resolver, security-aware server. Have I missed something? Which of these are the cases where you think (a) cache poisoning is possible at the recursive resolver and (b) the stub resolver can be fooled by Mallory? Best, A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
