On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: > > This origin authentication and integrity is precisely what is > required > > to avoid the DNS cache poisoning which is the kind of vulnerability > > which prompted this discussion. > > As has been discussed in the thread, DNSSEC is NOT a protection > against cache poisoning, because caches poisoned with forged > certificate breaks the security. > I think you need to explain how this happens in detail. For instance, an attacker wishes to poison the cache of some ISP's DNS server for 'example.com.". Currently, it gets the server to request information about example.com from its authoritative server, and sends information that purports to be from that server. It needs to guess some properties of the original request, but there have been and are various features of DNS servers which make this easier than you might think. Without DNSSEC, the attacked DNS resolver simply accepts the information. With DNSSEC, a security aware resolver will want to check the signature. The information is only accepted if the signature checks out, and the key is trusted. If the key is a trust anchor, then the check is complete. If not, then the resolver needs to get the DS RR for example.com from com's DNS server. This information is itself signed with com's signing key. So, it will not accept that unless it verifies. If com's signing key is not a trust anchor, then it will get com's DS RR from the root. Also signed by root, and the root key is probably a trust anchor. If any of this information is not available, or is not signed, then the trust chain is not present, and the original information is not accepted by the security aware resolver. So, perhaps you can explain how an attacker can get a security aware resolver to accept information which will subvert this? I think you have proposed that an attacker might explicitly subvert the chain. In this case it would involve getting the com DNS server to accept a DS RR for example.com. This is altogether harder problem for the attacker, and is of a significantly different character than cache poisoning, as it involves actual changes to the DNS servers, rather than just persuading resolvers to accept incorrect information. But, perhaps this mechanism would better be reported to people other than the asrg. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf