On Wed, Aug 20, 2014 at 03:38:41PM +0000, Hosnieh Rafiee wrote: > > So in long term there is no benefit to use encryption without authentication > in resolver scenario.
Let us be concrete. There are four cases: 1. A stub that connects to whatever resolver it gets by magic from DHCP. 2. A stub that connects to a specific resolver on the same network as itself. This is like your ISP's resolver, when you specifically configure the resolver. 3. A stub that connects to a specific resolver over the public Internet. This is like using Google's public DNS service. 4. A full-service resolver. In (1), othing can help, because DHCP is kind of trivial to subvert, so you could be talking to anything. In (2), your arguments sort of work, because the attack is localized attempting to snarf _particular_ traffic. In (3), however, your arguments don't work: the threat is not actually to particular traffic, but to _all_ traffic; and any attack that would actually depend on spoofing addresses or the like would be observable by the service provider, which foils the attack. In (4), of course, we don't have the problem. I include it because the validating stub in effect ends up having to chase most things itself, so it devolves to this. Your argument works if one is trying to prevent someone getting particular traffic. If the threat, however, is the general snarfing up of all the traffic towards a particular resolver with the goal of learning about all of its traffic, then even if some of it leaks that's not a big deal. In this case, failing to authenticate the resolver presents no real additional vulnerability. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
