Subject: [dns-privacy] Summary of the thoughts about DNS privacy

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Aug 2014 21:17:10 +0200

Folks,

I summarize all MY thoughts here. If you are object or think I am wrong, please argue with your reasons and give an example. 

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.
If you think when your domain is signed by DNSSEC, a fake resolver cannot cause any problem for you, I gives you an example. You can argue with your own example.

This is the scenario where there is no authentication but a  record is supposed to signed by a DNSSEC server. 
A domain called www.example.com signed by DNSSEC A.  
Client B wants to browse "www.example.com". 
It asks the IP address of this from resolver C. Attacker D spoof the IP address of resolver C and response to this query with the IP address of his own server F. If the client supports DNSSEC then, the attacker sign www.example.com with address of server F using his own key and sends it back to client B.
Client B needs to verify resolver C. The problem here is that Client B only knows resolver C and needs to ask the other queries from Resolver C. These include the IP address of example.com, .com and . to verify the key sent by resolver C. 
Resolver C answers all queries with wrong IP addresses that so that all queries ends to itself or one of the servers of himself. 
So, either client B encrypt the queries send back and forth to the resolver, it ends to the case where the unwanted person can still eavesdrop this communication by directly answer to the node in place of resolver.

In my opinion it does not matter whether this record is signed or encrypted, the attacker can directly be in the middle of the communication and forward all the packets to his desire place. So DNSSEC in this stage or last mile does not help.

2- Passive attack in resolver scenario seems inappropriate because an attacker can easily do active attack (as explained in item 1) and retrieve information it seeks. So he doesn’t need to do passive attack to retrieve domain  information. Maybe passive attacks happens after sending wrong information to victim node and it is for web application or etc. but not at the entry point.
The other reason is that node only once asks the resolver about the IP address of a certain website or server. Passive attack usually makes sense when there is a continuous communication between two nodes for a certain time. But this is not a case for resolver scenario where the attacker can actively introduced himself as a resolver. 

3-  For DNS privacy both encryption and authentication is necessary. When authentication is not possible, encryption doesn't help because of what explained in item 1 and 2. When encryption is not possible, this is where the passive attack makes sense because the attacker cannot claim to be a resolver (authentication will fail) so it uses his last chance to eavesdrop the communication. But in case authentication is not available, this attacker easily introduced himself as a resolver. This gives him more chance to obtain more information and even redirect all packets to his own place, infect user's computer or any further attacks.

Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Aug 2014 15:39:05 -0400

> It asks the IP address of this from resolver C. Attacker D spoof the IP address of resolver C and response to this query with the IP address of his own server F. If the client supports DNSSEC then,…

DNSSEC detects this case.  If you think it does not, you need to show
how.  I think you've misunderstood how DNSSEC works.

In order for an attacker to do that, it has to be able to insert its
own key on both sides of the zone cut.  This works all the way up the
chain until you get to the trust anchor, which the validator is
supposed to have configured.  You build this chain of trust from the
root for each validation.  If you think that can be subverted, you
have to say how.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Aug 2014 16:00:14 +0200

On Tue, Aug 19, 2014 at 09:17:10PM +0200,
 Hosnieh Rafiee <[email-masked]> wrote 
 a message of 59 lines which said:

> If you think when your domain is signed by DNSSEC, a fake resolver
> cannot cause any problem for you, I gives you an example. 

[Andrew Sullivan explained why this example depends on a lack of
understanding of DNSSEC.]

> But this is not a case for resolver scenario where the attacker can
> actively introduced himself as a resolver. 

[Paul Wouters already explained that it makes no sense to authentify a
DHCP-obtained resolver - since DHCP itself is not secure. You
authentify hard-wired resolvers only.]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 14:20:41 +0000

Hi Stephane,

> On Tue, Aug 19, 2014 at 09:17:10PM +0200,  Hosnieh Rafiee
> <[email-masked]> wrote  a message of 59 lines which said:
> 

Probably I could not explain exactly my meaning.  Please check my answer to Carsten and the revised version of that sample.

The important thing is stub resolver is not recursive resolver and the expectation of querying different authoritative DNSSEC server for this verification seems to be impractical. 

> authentify hard-wired resolvers only.]

:-) and my answer was that in this case, it does not make sense to do any encryption because we are boiling the ocean water as the observer already can play a role of resolver and access the data that we try to hide him.
My other answer was also was the attempts to secure DHCP and authentication. 

Encryption without authentication is like someone hide his head in the sand and assume that he has privacy while others can see his body clearly. 

Best,
Hosnieh

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 14:23:42 +0000

> Encryption without authentication is like someone hide his head in the sand
> and assume that he has privacy while others can see his body clearly.

You will not know if I will authenticate until you've attacked my
traffic. This is game over for an attacker that must go undetected.
Encryption puts their head in the sand and if they try to pull it out,
they risk detection at a non-zero cost.

Make them pay.

All the best,
Jacob

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Aug 2014 16:28:21 +0200

On Wed, Aug 20, 2014 at 02:20:41PM +0000,
 Hosnieh Rafiee <[email-masked]> wrote 
 a message of 37 lines which said:

> Probably I could not explain exactly my meaning.  Please check my
> answer to Carsten and the revised version of that sample.

Yes and you made the same mistake, as Carsten patiently explained to
you.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Aug 2014 10:32:48 -0400 (EDT)

> The important thing is stub resolver is not recursive resolver and the expectation of querying different authoritative DNSSEC server for this verification seems to be impractical.

So you have two choices in that case:
1 Become a dnssec validating resolver
2 Setup a VPN to a validating resolver you trust

Both are out of scope for this draft.

> :-) and my answer was that in this case, it does not make sense to do any encryption because we are boiling the ocean water as the observer already can play a role of resolver and access the data t…

No, an OBSERVER cannot. Only an active attacker can. In the absence of
2) that is the best you can do, and this draft says it is the best you
SHOULD do.

> Encryption without authentication is like someone hide his head in the sand and assume that he has privacy while others can see his body clearly.

With nation state monitoring out of control, this is not true.
Especially when using non-local resolvers like 8.8.8.8.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 14:35:42 +0000

Hi Jacob,

> they risk detection at a non-zero cost.

If you use that kind of encryption without authentication in other scenario, I would agree with you that it helps because only the first point of communication the attack might happen. 

But here for resolver.. ..NO..., this is not the first point. Either the attacker is prepared to receive your information or not. If he is prepared, he is already your resolver and you connect directly to him and hand on your data to him. Then who are you afraid to retrieve your data??
if he is not ready to retrieve your data or eavesdrop, then since this communication is not continuous and only there is two messages exchanged with the DNS resolver, then he has no chance to receive your data. Did encryption help here? No... why? Because the attacker wasn't yet prepared otherwise he was your resolver. 
In other words, encryption help if there is continuous data exchange for a certain time (but not only 2 messages) that might allow unwanted person to eavesdrop.   

Best,
Hosnieh

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 15:02:30 +0000

On 8/20/14, Hosnieh Rafiee <[email-masked]> wrote:
> If you use that kind of encryption without authentication in other scenario,
> I would agree with you that it helps because only the first point of
> communication the attack might happen.

I don't think I understand what you are trying to express in the above
statement. Could you rephrase it?

>
> But here for resolver.. ..NO..., this is not the first point. Either the
> attacker is prepared to receive your information or not. If he is prepared,
> he is already your resolver and you connect directly to him and hand on your
> data to him.

This is false. Sniffers are not always on the same path as injectors.
A sniffer is not a resolver. A resolver may be malicious. The network
may try to impersonate my resolver. In the second case, I'd like a way
to detect that someone is trying to impersonate (eg: authentication
via DANE record, etc) my resolver. In the first case, I'll use a
resolver that I trust.

> Then who are you afraid to retrieve your data??

I'm not sure that I understand your quesiton?

> if he is not ready to retrieve your data or eavesdrop, then since this
> communication is not continuous and only there is two messages exchanged
> with the DNS resolver, then he has no chance to receive your data. Did
> encryption help here? No... why? Because the attacker wasn't yet prepared
> otherwise he was your resolver.

Huh?

> In other words, encryption help if there is continuous data exchange for a
> certain time (but not only 2 messages) that might allow unwanted person to
> eavesdrop.

If I configure my stub to trust my recursive resolver from the start,
I should have zero unencrypted connections. If I am a locally
verifying, DNSSEC enabled recursive resolver, I would like the traffic
to look identical (per connection) as if it was from an encrypted stub
resolver.

All the best,
Jacob

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 15:13:01 +0000

> > The important thing is stub resolver is not recursive resolver and
> the expectation of querying different authoritative DNSSEC server for
> this verification seems to be impractical.
> 

Then it appears that everything is out of scope... 
 
> 
> >> [Paul Wouters already explained that it makes no sense to authentify
> >> a DHCP-obtained resolver - since DHCP itself is not secure. You
> > :-) and my answer was that in this case, it does not make sense to do
> any encryption because we are boiling the ocean water as the observer
> already can play a role of resolver and access the data that we try to
> hide him.
> 

Again there is no observer when he can easily have a role of resolver (or active attacker) without being detected. There is either an active attacker or no one. Please tell me how long does it take that a query sends and receives. Isn't it more than a few seconds.

Why should I as an attacker waste my time to use wireshark or etc to listen to all queries in a hope that I can receive some information. When I can execute easier step and retrieve much more information without being detected?

> > Encryption without authentication is like someone hide his head in
> the sand and assume that he has privacy while others can see his body
> clearly.
> 

I presume that the attacker is either inside your own network or where he can access to the network that your DNS messages pass by. In both cases, he can easily spoof the IP address of google DNS server and all your traffic goes through him. This is the case where he is interested in your communication. So either you encrypt your data or not, he has this access. 
:-) is attacker a government, then he can again be an active attacker. Who can detect him? 

Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 21 Aug 2014 08:38:49 +0000

Jacob,

 I am sorry, I just skipped answering your messages directly. Because I thought the ongoing discussion with Andrew would/will cover many other questions.

The other problem is that I am only one person and flooded with many messages....(so quick answering messages to not forget what is it in my mind... led to poor English messages or not understandable messages so that people had different interpretations. since it was only like quick thoughts without having time to expand them :-) )

In any case if the discussion did not cover your answer, I will directly answer your two(?) messages.

Only briefly I answer a few of them that I think I did not cover...

Best,
Hosnieh

> to detect that someone is trying to impersonate (eg: authentication via
> DANE record, etc) my resolver. In the first case, I'll use a resolver
> that I trust.

As you are yourself a DNS expert, DNS is application layer and not only related to local links, so the place of injectors can be anywhere in the network. If the DNS port on network devices, inbound  and outbound are open then the location of injectors are not important.

> I'm not sure that I understand your quesiton?

I meant the people who are interested in your traffic.

> > In other words, encryption help if there is continuous data exchange
> > for a certain time (but not only 2 messages) that might allow
> unwanted
> > person to eavesdrop.
> 
> If I configure my stub to trust my recursive resolver from the start, I
> should have zero unencrypted connections. If I am a locally verifying,
> DNSSEC enabled recursive resolver, I would like the traffic to look
> identical (per connection) as if it was from an encrypted stub resolver.

No, if the approach you use supports encryption and authentication. Then you have a complete case like item 4 of Andrew's message.