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

Hi Andrew,

> On Wed, Aug 20, 2014 at 12:06:29AM +0200, Hosnieh Rafiee wrote:
> > 1-  Opportunistic encryption is not appropriate for the privacy of
> > stub resolver to recursive resolver scenario unless the node has a
> > possibility to authenticate this resolver.

> I don't think this is true.  The point of the encryption independent of
> authentication is for the case where you've decided to accept the risk
> that your upstream resolver isn't actually trustworthy, and have
> decided to trust it anyway.  You're welcome to say, "That's a bad
> decision," but I don't think you've provided a reason that others can't
> make that trade-off reasonably.

I provided several reason that the observer doesn't exist. It bothers nobody and not easily detectable when an observer change his role to an active attacker. it is not easy to detect even an active fake resolver. He can only be active for a certain time and stop when he retrieve information he needs. 
In public network, there is no control over this... so he can do whatever he want and leave the network silently.
In private network like an enterprise, you colleague only filter your request and answer to the request of your computer and then play a role of resolver.
There is one question here. Why do you want to encrypt the communication between your stub resolver and the resolver?
Let me gives you some hints.. because...
1- the node is in an unsecure environment and you do not want that others see where you connect
2- the node is in secure environment but you do not want that your colleague see where you connect

Answers:
1- If you are in unsecure environment either there is someone who interested in all information and instead of observing, change his role and introduce himself as a resolver. So encryption ends to him. Then the question is who you hide your data from? Why did you bother yourself to encrypt your message?
2- If you are in a secure environment either your colleague is interested to receive your data, then he again do not play a role of observer and change it to active attack.

What I tried to explain here is that an observer role doesn't make sense in resolver scenario. Someone observe something when he has no possibility to do other things or wants to gather information for further attacks. If it is a real attacker, he knows how to change his role to a resolver and gather all information. Then you protect the data from whom?



> > If you think when your domain is signed by DNSSEC, a fake resolver
> > cannot cause any problem for you
> 
> This has nothing at all to do with DNSSEC.  I think you're just
> muddying the waters by bringing DNSSEC into it.  It is _certainly_ true
> that you can't trust DNSSEC validation without knowing exactly who did
> the validation and having an authenticated channel to that.
> That's completely unrelated to the privacy argument for stub-to-
> resolver encryption.

DNSSEC just came to this game when some folks say that DNSSEC can protect this and they only need encryption. 

And my answer was only to those folks that DNSSEC cannot do this at the moment and will not be able to process this easily because
- it is complex...

So, here are some assumption that might never happen and there is a theory that dependent to those assumption. 
It is like having a plan of building that there is no bricks to complete it and everything is like a dream.

Best,
Hosnieh