> No, you're missing the point. It's not _a user_. It's _all users_. > That is, the point is not to protect this or that particular user or this or that > particular transaction. It is to prevent wide-scale harvesting of _all traffic_, in > which any particular user's data might be. If someone is attempting to > develop an overall picture of both what is happening on the Internet, and > what a particular user is doing, and to correlate the one with the other, then > you need all the traffic, and by that you can both identify new people "of > interest" > and identify overall patterns.
You're right but having all traffic means that this observer have a wide access to several backbone devices or the traffic passed by... "A user" is an example to simplify the problem space. I can also generalize it to all users... see at the end of this message please... > But if people encrypt this data, then you either have to subvert the recursive > server But what you do is only closing your eyes and assume that everything is fine.... see my example at the end. Your argument is that we benefit from encryption because they might not have any possibility to observe all traffic. I say it depends on the location of your observer/s... > > 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? > > I agree with neither of those premises. Public servers are not behind NAT > (and even if they are, knowing the public service address is enough). Similarly > with end users. And there are plenty of DNS servers on v6. > I didn't say that public servers are behind NAT. I was talking about users that I presumed you were also talking about.. Ok if you say most DNS server supports IPv6.. I only say that it is fine. Because again this is the same scenario but only the IP of query requester might reveal a certain node....IN other words, Just with IPv6, the IP address might directly point to a certain node. If you are talking about the communication of a DNS server with another server that both are not behind NAT. This is also not different. It is like IPv6 scenario. You say it is about all users. Ok I agree.. but the place of observer is important. Wherever he is located, if he is able to watch the encrypted traffic, he is able to watch the next flows as well. he can watch the case where an encrypted data comes to a DNS server and then another data flows started to other server. In other words, he can also watch where this data goes after DNS server. It is just a mapping without any need to have any knowledge about the content of DNS server query request and response. Next flow automatically reveal the content of this *encrypted* DNS messages... The observer that can correlate data seems to be so sophisticated and know data mining approach and it is not hard for him to only map two flows with the same initiated IP (just generalize it to all traffic...) Only an example of what will be happening...Encrypted traffic from IP x goes to public DNS server B. observer is only watching without active attack. Next flow shows that there is traffic from IP x to website C. the node with IP x could encrypt data and sent it to DNSserver B. But couldn't hide the content of data sent to DNS server B, even though encryption happened. Because next flow with the same IP to website C exposed the content of last flow initiated from the same IP. observer watched it without much efforts. Now generalize it to all traffic flows that goes to a public resolver and then goes to somewhere else for all users... If the target problem is to really hide the traffic and avoid the correlations and avoid learning the pattern then I guess your approach is not correct. You only need end-to-end tunneling and not only encryption because there is a need to all flows comes from IP addresses. The flows that passed by observers' sniffers. In other words, network layer helps to leak information about flows.... Best, Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
