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

 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