Andrew, > 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. I am not agree on this point. This point actually flashed a new idea on a possible attack that I haven't thought before.... so now encryption doesn't help user's privacy if this is for item 3. Before going further, I start with a question and some reasons as follows. Question: What is specific about that sort of traffic in item 3 when the observers can easily obtain those domains themselves from those public DNS servers or from some public websites that gathered all domain names (like ALEXA or etc.) What do we want to hide in those traffics? If I get answer to this question, maybe I get convinced that an observer makes sense for this scenario and encryption helps without authentication. reason: there is almost no *actual* valid IPv4 addresses ( all nodes are behind a NAT) and often DNS servers do not support IPv6 addresses. Do you agree? In other words, that traffic does not show any actual person to hide his/her privacy. It is just a general IP addresses that requested a certain website. This is different than the argument of Paul about Wifi (that argument is on point 2 or 1) did I understand you correctly that you agree with my argument about active attack instead of observer? (if not I probably misunderstood you and please correct me) So, in my opinion, the observer is interested only certain data. DNS server only point a person to certain server or website or whatever service available. If the observer sit where the traffic of one of backbone routers passed by and interested on the information comes from a certain network, what he might do is 1-he filters that traffic based on the IP address (this IP address is of course belongs to a certain network) , He even doesn't care whether or the traffic to DNS server is encrypted. He might also not play a role of active attacker -- if you say he will be detected... (of course I doubt, because he might be detected if he does this for a long time)-- 2- He sees that the traffic goes to DNS server but encrypted. His filters show that next traffic goes to certain website... or server...OK!... then what was hidden for him? Isn't it the traffic that we wanted to hide from him by using an encryption mechanism. In other words, isn't it that encrypted traffic that easily observed by this unwanted person? > 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. Now I think it works even without that.. if you really like to use only observer in your traffic. Best, Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
