Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

["Hosnieh Rafiee" <[e-mail]>]

> 
> This is the nub of your latest argument.

Your own classification bring this new 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.

Agreed.. this is the topic of discussion

> Therefore, the flow of network traffic toward those recursors is
attractive for
> surveillance.  Right?  That's anyway the circumstance I'm thinking about.

Not quite sure... the next flow is attractive for him and not exactly the
flows go to recursive DNS server , if, according to your last message the
actor want to find a behavior patterns between different flows or analyses
the user behaviors...
The next flows actually goes to a server or a website.

> 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), 

I am not sure about the second part... why the surveillance actor needs to
do  the correlation between authoritative name servers and recursive? based
on the information available in stub resolver query request... he already
has all data .. and he doesn't need to go step by step up.. I don't think
that he wants to find the DNS servers..  In other words, the first query
gave all those information. 

So could you please clarify what kind of correlation you mean here?

>and then correlate the action
> with another outbound flow toward whatever service the original user was
> planning to connect to.

I think here.. he doesn't need this correlation. Because, if behavior
patterns are what he looks or  what user usually browse, search, connect,
etc. per day.. then the next flow is important.

> 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.

This is what I am not quite agree on. In my opinion, our current problem is
the wrong focus about privacy. In other words, it appears to me that the
focus is only on some domain names . While I think domain names alone give
no meaningful and useful information to anyone... but the next flow gives
important information that is the correlation between a flows from end user
to a service (servers but not DNS servers) but with this way of encryption
we did not hide this correlation and still exist. (it appears that for this
correlation the solution is like what I said in last message, tunneling to
hide not only the first flow but the next interesting flows).

So, this is the case that I think encryption doesn't make this process
expensive unless the surveillance actor have no possibility to sniff the
next flows  . (the flows from end user to a service like a webserver)
without the help of a recursive DNS server. . If this is the case, I agree
with your argument... otherwise encryption doesn't change anything since our
target person in discussion is looking for something else and we encrypted
something that was in no interest of this person.

To be clear, please just focus on this scenario where a surveillance actor
just skip any traffic goes to a recursive DNS server. But he analyses
traffics that comes from users to services. If he has this access to analyze
this traffic. He can do this without bothering himself as he is not
interested to complicate his data analysis by following the traffic goes to
DNS recursive. Therefore, He directly follow traffics that initiated from
different users and goes to certain unknown locations. 

In other words, recursive DNS server is only the helper tool or that flow is
only a helper flow, But this helper flow only works in case where the
surveillance actor has no possibility to sniff the next interesting flows.
But in your example, it appears that this is not a case and he want no
meaningful correlation between DNS flows and next flows. While, I think,
directly he can have next flows without this correlation. So, when he have
access to both traffic flows (DNS recursive and flows end users to
services)... why he should bother himself to sniff traffic to DNS server
that is of no interest?


> 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.

This is one approach to solve the problem and I am sure you and all people
in IETF are familiar with (Divide and conquer algorithms).. in other words,
such problem cannot be easily understood if we do not make it as  simple as
possible. After the solution works for simple case we can also extend it to
larger case and see whether or not it still works. Then at the end we can
evaluate the solution to this problem as a whole...

Best,
Hosnieh