[I suspect you may know much of this, but just in case...] On Sep 24, 2010, at 5:16 PM, John Levine wrote: >> Plan A: few consumers will use DNSSEC between their PCs and the ISP's >> resolver, so they won't notice. In general, consumers won't be using DNSSEC between their PCs and ISPs. PCs typically use stub resolvers and while there are ways to secure the communication between the stub resolver and the ISP's (perhaps validating) resolver, namely SIG(0) or TSIG, I don't know of any implementations that make this easy enough for your average end user to use and in the case of TSIG, (symmetric) key management will be a bear. Given existing prevalent technology, you either trust your ISP and the communication path between yourself and that ISP or you run your own validating resolver. Note that if you take the latter route, you'll often find yourself frustrated when you try to roam on services like T-Mobile Hotspot (you _must_ use their resolver for initial validation). >> Plan B: consumers will observe that malicious impersonation of far away >> DNS servers is rare and exotic, but malware spam arrives hourly, so they >> will make a rational tradeoff, take their ISP's advice, and turn off >> DNSSEC. Not sure I see the relationship between malware spam and DNSSEC. Given most validation occurs at the ISP, in the case of an actual DNSSEC-preventable attack the end user will most likely get a friendly message from their web browser saying "can't find the server" or perhaps bounced mail because the destination email address didn't resolve. The end user will then call the ISP and say "Internet's broke. Fix it!". In the cases where an actual cache poisoning attack is taking place (which, I'm told, is actually occurring thanks to scripts that implement the "Kaminsky Method"), the ISP end user support staff can say "Hah! We protected you from Evil!". In the (likely more frequent) cases where a signature has expired or there is some other misconfiguration, the ISP end user support staff can say "try this IP address". If the domain is popular enough, the ISP could even pre-populate their cache with the correct IP address so they stop getting support calls. However, I suspect if enough of the misconfiguration-variety of validation failures oc cur, the ISP will get tired of the additional support cost and turn off DNSSEC. > Something else occurs to me: > > Plan C: Sophisticated ISPs might configure their own DNSSEC key into > customer resolvers, and sign replacement records with that. Given current technology, I suspect this would be rather unlikely since it implies the customer is bright enough to set up their own validating resolver. In such cases, I'd think the customer would question why their ISP is asking them to use an ISP-specific trust anchor. > The threat model for DNSSEC has always been, approximately, that the > authoritative server at the far end is friendly, and the middleboxes > are hostile. It's more that the authoritative server is ... well, authoritative and that anything in between can't really be trusted. > But we have real situtations where the opposite is true, > quite possibly more often than the other way around. Hmm. Are you talking about SiteFinder-like services? > If we want people deploying DNSSEC widely, we need to make sure it > handles the actual threats they face. As I mentioned, I have been told by reputable sources that folks are actually experiencing the Kaminsky method cache poisoning attacks, so that threat is real. The problem is that some folks have been trumpeting DNSSEC as a solution to many problems when in fact, it solves a relatively rare (albeit real) attack. All DNSSEC really does is ensure a DNS response hasn't been mucked with in transit from the authoritative server to the validating resolver. DNSSEC can't help you between the validating resolver and the originating requester if you can't trust that path and it can't help you if you can't trust the authoritative server. DNSSEC may be used as a trustable infrastructure to allow folks to do other things (see the keyassure proto-wg), but that's in the future... > PS: If I plug my random Windows PC or Mac into a cable modem, and I tell > it to use DNSSEC, where does it get the top level validation keys? In order to use DNSSEC (at least today), you have to run a validating resolver on your PC or Mac and you have to specify the trust anchor(s) in the name server configuration file. The trust anchor you'd most likely want to configure is available from http://data.iana.org/root-anchors/. Presumably, if you're ambitious enough to figure out how to run your own validating resolver, you'll be able to figure out how to add the trust anchor to your config file. Or at least that's the theory... Regards, -drc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf