On Fri, Nov 28, 2008 at 10:09:16AM -0500, John C Klensin wrote: > ones) are the most likely targets of attacks. If they are, then > having DNSSEC verification only to those servers, with client > machines trusting the nearby caching servers without DNSSEC > protection, provides very little protection at all. Put > differently, if we cannot extend DNSSEC protection and > verification to the desktop, DNSSEC provides very little > marginal security advantage.
This doesn't actually follow, because there could be another way to validate the link between the end host and the validating recursive resolver. For instance, we could use TSIG between a non-validating stub resolver and a validating recursive resolver in order to ensure that attacks between those two points aren't successful. If I know I have the right node doing the validation for me, then attacks against the ISP's validating recursive resolver require complete takeover of that machine: by no means impossible, for sure, but a bigger deal than just spoofing answers to a stub resolver. That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. > As several people have pointed out, effective use of DNSSEC to > the desktop requires sufficient work on APIs and UIs that an > application, or the user, can distinguish between "signed and > validated", "signed but does not validate", and "unsigned". Why? It seems to me that acceptable definitions of "works" and "doesn't work" in a security-aware context could include "validated or insecure delegation" and "bogus delegation" respectively. In my opinion, any plans that involve users making sensible security trade-offs due to validation failures will get us right back where we are with self-signed or expired (or both) certificates for https. It seems a perfectly good idea to me that "bogus" means exactly the same thing as "site off the air". As a DNS geek, I'd _prefer_ more-intelligent end points with respect to the DNS. But I don't buy the argument that they're a necessary condition for DNSSEC deployment. > the middlebox problem, with servers not under the user's control > making decisions about whether or not particular strings are > resolved or reported to the user machine as non-existent. I > have not been following the DNSSEC protocol work closely enough > to be sure, but my impression is that such protocol work has not > even been started, much less concluded and standardized. You have exactly two options: allow the recursive server to make the decisions you seem to dislike -- and I think people who like that approach think it's a feature, not a bug -- or else to do validation out at the end nodes. The end node gets a bit to tell upstream validators that it is going to do all validation itself, and those upstream systems are required to pass along all the data necessary for such validation. So it's still possible to do everything at the end node. This is quite independent of the question of whether applications have the ability to understand the results from the validator. I agree that OS APIs seem to be missing. I'm not sure that's something the IETF ought to be solving, but I'd happily entertain arguments either way. > several of them, do we need search rules for look-aside > databases My personal reading of the current specifications is that, if you have at least one path to validation, then validation is supposed to work. So search rules ought not to be needed. What the implementations actually do is currently at variance with my interpretation, however. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf