On Thu, Aug 21, 2014 at 12:28:15AM +0200, Hosnieh Rafiee wrote: > knowledge about the content of DNS server query request and response. Next > flow automatically reveal the content of this *encrypted* DNS messages...
This is the nub of your latest argument. So that we're clear: we're imagining a defence against wide-spread surveillance enabled in part by the fact that there is a concentration of very large recursive resolvers that historically not been the case. Therefore, the flow of network traffic toward those recursors is attractive for surveillance. Right? That's anyway the circumstance I'm thinking about. Remember, we're only talking about last hop encryption. This argument actually relies on concentration of the queries at centralish places. Now, under your new concern, the surveillance actor must correlate a given encrypted query flow towards a resolver with a very large user (client) population, correlate that resolver query with a _possible_ outbound query from the recursive server to the relevant authoritative servers (which of course might not happen because of caches), and then correlate the action with another outbound flow toward whatever service the original user was planning to connect to. I am very far from believing any more that nobody could do this kind of large-scale analysis, but it certainly makes the kind of surveillance we're talking about way harder and way more expensive. That doesn't seem like nothing. As an aside, you say > map two flows with the same initiated IP (just generalize it to all > traffic...) This misses the fundamental problem in the way you're approaching this issue: "just generalise" from specific to all cases. But while set-theoretic expansion works trivially that way, in practice things are harder to achieve. "Just generalise" is the way that Internet services that work just fine for 200 do not work at all for 2 000 000. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
