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

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 20 Aug 2014 00:06:29 +0200

I change my story a bit based on some offlist discussions ...

So the point 1 from summary email changes like this
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. The client cannot verify this attacker in any case since it is
only a stub resolver and dependent to a recursive resolver for query
different authoritative DNS server in order to verify this DNSSEC server.
This is why the stub resolver accepts whatever receives from this fake
DNSSEC server. 

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 stub resolver has no possibility to verify that record. So, an 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. 

> > How can you sign DNSSEC data without being in the posession of the
> > private signing key(s) all the way to the root?

So based on the revision in item 1. I can also revise my answer here.

I don't need to sign the DNSSEC data since the stub resolver is dependent to
me (or a DNSSEC recursive resolver) to verify any other DNSSEC server. 

Best,
Hosnieh

---

From: Carsten Strotmann <[email-masked]>
Date: Wed, 20 Aug 2014 07:20:08 +0200

Hello Hosnieh,

> me (or a DNSSEC recursive resolver) to verify any other DNSSEC server. 

As the draft mentioned the stub-resolver cannot rely on the DNSSEC
validation of an un-authenticated, unknown DNS resolver. 

Either the stub-resolver, or the application, needs to do the DNSSEC
validation. While not widely deployed, this is possible today. 

For this local validation, the stub-resolver or the application has one
or more DNSSEC "well-known" trust-anchors (like the DNS root zone trust
anchor, or the ".de" zone trust anchor) pre-configured. The validation
does not rely on the any data received via the unautenticated DNS
resolver. The integrety of DNSSEC signed DNS zone data can always be
checked.

A malicious unauthenticated and unknown DNS resolver can stop all
communication by providing false DNS data, but the false data is always
detected.

DNSSEC validation does not rely on the the data received through the DNS
resolver, which might be malicious. The trust anchor is configured
before this communication, out-of-band, coming with the software or
manually configured.

-- Carsten
-- 
Sent with my mu4e

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 20 Aug 2014 08:25:06 +0200

Hi Carsten,

Thanks again for your response.
The problem about this draft is that, they did not consider authentication
as a necessary step and only presumed that some other services would do this
task for them and they only focused on encryption. All the discussion back
and forth is because I think the focus should be on both and encryption
alone let the observer to retrieve and watch the data.  In other words, for
instance if a service implement such draft, it fails if they do not change
their focus on both. 

What I understand from privacy is that we want to disallow an observer to
watch our data. This observer is usually inside our own network or somewhere
in our network where our first point of this communication is also a
resolver that we might not be able to trust because it is not clear it is a
trusted resolver or a fake one. So when an observer can easily change his
role to one of this fake resolver and watch data. Encryption ends to him. 

> validation of an un-authenticated, unknown DNS resolver.

This is why I said there is missing part in this draft. "cannot" is
different than offering a certain solution. 

> validation. While not widely deployed, this is possible today.

I think this not the task of stub-resolver. If stub resolver supposed to
play a role of recursive resolver and query different authoritative DNSSEC
servers from "." to "www.example.com" , then it is not called a stub
resolver and it is recursive resolver.  So then the question is what is the
task of recursive resolver? Is there any plan to change all stub resolver in
future to recursive resolver and remove the recursive resolvers on internet?

If purpose is to give these tasks to other services then I think it needs to
be mentioned clearly in the draft that "HOW" this can be done. This is all
what effect on privacy consideration of the draft and , of course, the
implementation of this draft and important because again encryption alone
does not make sense either they use opportunistic encryption or be lucky and
use  a fixed encryption approach. (people think I am against opportunistic
encryption but this is different, I am against encryption without secure
authentication) So that, all implements this approach and always encrypt the
packets. As far as the observer has the easy opportunity to forge the
identity of a resolver, encryption is like boiling the ocean water. 

The problem is that , often, like the example of wifi connection, the node
is anonymous. Do you plan to preconfigured all nodes inside a network with
the preconfigured value of some trusted anchors? This is especially really
difficult when the nodes in a network are dynamic like a wifi connection. 

I guess the problem here is not well defined... in my opinion the problems
that a draft needs to address for privacy consideration are as followings:

- secure robust authentication (essential)
- encryption (good to have)
- automation to whatever extend possible (essential)
And of course performance (good to have)

Maybe if you install an active directory, you solve all this problems but
you cannot trust all nodes in a public network to join to your domain that
they can access to the list of trusted anchors and can automate this task to
some extend. 
If this was an easy task or feasible task,  there wasn't always a discussion
about DNSSEC and last mile of Internet.... 

> For this local validation, the stub-resolver or the application has one or
more
> DNSSEC "well-known" trust-anchors (like the DNS root zone trust anchor, or
> the ".de" zone trust anchor) pre-configured. The validation does not rely
on
> the any data received via the unautenticated DNS resolver. The integrety
of
> DNSSEC signed DNS zone data can always be checked.

Not stub resolver but the recursive resolvers usually preconfigured with
what you say. But the problem here is real task of stub resolvers and what
they are expected to do. 

And the application here in my opinion is out of scope otherwise they plan
to say this draft is very dependent to x application to do this
authentication and without this, the implementation of such approach is not
really helpful because the observer has a chance to easily forge the
identity of the resolvers.

> resolver, which might be malicious. The trust anchor is configured before
this
> communication, out-of-band, coming with the software or manually
> configured.

This actually not the question of what DNSSEC can do . But here is the
question of how to solve privacy problem (if the plan is to also use DNSSEC
as a part then the question is what DNSSEC cannot do and what the drafts
should address to assist what it cannot do.) 

Thanks,
Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 10:34:53 -0400

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

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

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

Hi Andrew,

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 11:23:44 -0400

On Wed, Aug 20, 2014 at 03:00:05PM +0000, Hosnieh Rafiee wrote:

> I provided several reason that the observer doesn't exist. 

No, you provided several reasons why you think this decision is an
unreasonable one.  Prior to the evidence from a couple years ago that
national governments were doing wide-spread vacuuming up of everything
they could by perfoming passive attack through the means of tapping
lines and so on, the position you are taking was entirely reasonable.
But in the face of that evidence, some people have decided that, even
if they can't protect themselves reliably all the time, they get
enough marginal benefit from privacy to do it whenever they can, even
if it's not perfect and not terribly hard to subvert.

In other words, you are basically arguing that the benefit that will
accrue from this technique is not enough given the costs.  Others
disagree with you.  Your argument only works if we accept your premise
that the benefit is not worth the cost; if we evaluate the benefit
differently, then the cost might be acceptable.

> What I tried to explain here is that an observer role doesn't make sense in resolver scenario. 

Except that we have an existence proof that it does.

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

If you had strong authentication of the resolver, then this would be
true.  Since TSIG (which I expect you remember) or SIG(0) can solve
the authentication part, then in fact the only thing you would need
_is_ encryption, and then you could rely on the DNSSEC piece as well.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

> if they can't protect themselves reliably all the time, they get enough
> marginal benefit from privacy to do it whenever they can, even if it's
> not perfect and not terribly hard to subvert.
> 

True. Because the people who you are scaring from to eavesdrop the communication already know how you want to process this...

To be clear... IF this approach wasn't public and not known, then you might benefit from it but when something is public and known, what you would do as an attacker? Do you still wait in a hope of receiving plain text information or easily change your role to a resolver and receive information you want as it is not hard to detect.

So in long term there is no benefit to use encryption without authentication in resolver scenario.  

> Except that we have an existence proof that it does.

It really doesn't... at least in this scenario. Why? Because this approach would be standard and well known... So, if anyone (or the whom you're talking about) before played the observer role now they would change their role because they are still interested to receive your data and your node is unable to detect this interceptions since whatever resolver you use is valid by your node either a fake resolver or a real resolver.

> > DNSSEC just came to this game when some folks say that DNSSEC can
> protect this and they only need encryption.
> 
> true.  Since TSIG (which I expect you remember) or SIG(0) can solve the
> authentication part, then in fact the only thing you would need _is_
> encryption, and then you could rely on the DNSSEC piece as well.
> 

We already know the problem with those approaches and as you said brining DNSSEC to this discussion doesn't make sense..

Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 11:55:23 -0400

> So in long term there is no benefit to use encryption without authentication in resolver scenario.  

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

Best regards,
 
A
-- 
Andrew Sullivan
[email-masked]

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 16:04:08 +0000

On 8/20/14, Hosnieh Rafiee <[email-masked]> wrote:
> True. Because the people who you are scaring from to eavesdrop the
> communication already know how you want to process this...

Huh?

>
> To be clear... IF this approach wasn't public and not known, then you might
> benefit from it but when something is public and known, what you would do as
> an attacker? Do you still wait in a hope of receiving plain text information
> or easily change your role to a resolver and receive information you want as
> it is not hard to detect.
>

I have not seen information that suggests strongly deployed TLS (with
a proper RNG) is broken by a passive observer. Do you have a citation
handy?

> So in long term there is no benefit to use encryption without authentication

There is a benefit - it forces Eve to become Mallory. Mallory risks
being caught red handed.

> It really doesn't... at least in this scenario. Why? Because this approach
> would be standard and well known... So, if anyone (or the whom you're
> talking about) before played the observer role now they would change their
> role because they are still interested to receive your data and your node is
> unable to detect this interceptions since whatever resolver you use is valid
> by your node either a fake resolver or a real resolver.
>

This is why authentication is important. If the authenticating and
non-authenticating resolver behave the same way on the network, it
will be very risky to tamper, even with a resolver that fails open.

Paul - perhaps this suggests that all stub and recursive resolvers
should log keying information, even if it isn't used for
validation/authentication/etc?

> We already know the problem with those approaches and as you said brining
> DNSSEC to this discussion doesn't make sense..
>

The point is that this solves the confidentiality issues that DNSSEC
doesn't solve. It should solve it but many DNSSEC folks refused to
address this issue. There are a variety of reasons and this draft by
Paul helps us to move past those previous decisions.

All the best,
Jacob

---

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

> validation/authentication/etc?

That is one "out of band" authentication mechanism called TOFU (trust on
first use) or LOF (Leap of Faith)

While possible, it will see a lot of false positives, like when going to
a different starbucks using the same wifi ESSID.

It could be done if one also logs mac address and/or lat/long info.

But these are all local policy and local implementations issues.

Paul

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 17:11:31 +0000

> first use) or LOF (Leap of Faith)

I'm suggesting that regardless of authentication, we should ensure
that we have some information for a user to report their experience.

> a different starbucks using the same wifi ESSID.

There is no false positive - only an actually observed certificate. :)

> But these are all local policy and local implementations issues.

I agree. I suggest that resolvers SHOULD log resolver certificate information.

All the best,
Jacob

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 20 Aug 2014 22:17:57 +0200

Andrew, 

> 1.  A stub that connects to whatever resolver it gets by magic from DHCP.
> 
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.
> 

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 17:23:32 -0400

> help user's privacy if this is for item 3. Before going further, I start
       ^^^^^^^^^^^^^^

No, you're missing the point.  It's not _a user_.  It's _all users_.
That is, the point is not to protect this or that particular user or
this or that particular transaction.  It is to prevent wide-scale
harvesting of _all traffic_, in which any particular user's data might
be.  If someone is attempting to develop an overall picture of both
what is happening on the Internet, and what a particular user is
doing, and to correlate the one with the other, then you need all the
traffic, and by that you can both identify new people "of interest"
and identify overall patterns.

But if people encrypt this data, then you either have to subvert the
recursive server (which you can do with court orders, of course, but
then your plan is exposed), or else you have to break the encryption.
Even if some of the traffic leaks past the encryption layer, the
attack _only_ works at large scale.

You don't seem to be taking that part of the argument seriously.
Until you concede it, there's nothing more to say.

As an aside,

> behind a NAT) and often DNS servers do not support IPv6 addresses. Do you

I agree with neither of those premises.  Public servers are not behind
NAT (and even if they are, knowing the public service address is
enough).  Similarly with end users.  And there are plenty of DNS
servers on v6.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Aug 2014 00:28:15 +0200

> That is, the point is not to protect this or that particular user or this
or that
> particular transaction.  It is to prevent wide-scale harvesting of _all
traffic_, in
> which any particular user's data might be.  If someone is attempting to
> develop an overall picture of both what is happening on the Internet, and
> what a particular user is doing, and to correlate the one with the other,
then
> you need all the traffic, and by that you can both identify new people "of
> interest"

You're right but having all traffic means that this observer have a wide
access to several backbone devices or the traffic passed by...
"A user" is an example to simplify the problem space. I can also generalize
it to all users... see at the end of this message please...

> But if people encrypt this data, then you either have to subvert the
recursive
> server 

But what you do is only closing your eyes and assume that everything is
fine.... see my example at the end.

Your argument is that we benefit from encryption because they might not have
any possibility to observe all traffic.  I say it depends on the location of
your observer/s... 

> > 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?
> 
> I agree with neither of those premises.  Public servers are not behind NAT
> (and even if they are, knowing the public service address is enough).
Similarly
> with end users.  And there are plenty of DNS servers on v6.
> 
I didn't say that public servers are behind NAT. I was talking about users
that I presumed you were also talking about..
Ok if you say most DNS server supports IPv6.. I only say that it is fine.
Because again this is the same scenario but only the IP of query requester
might reveal a certain node....IN other words, Just with IPv6, the IP
address might directly point to a certain node. 

If you are talking about the communication of a DNS server with another
server that both are not behind NAT. This is also not different. It is like
IPv6 scenario. 

You say it is about all users. Ok I agree.. but the place of observer is
important. Wherever he is located, if he is able to watch the encrypted
traffic, he is able to watch the next flows as well. he can watch the case
where an encrypted data comes to a DNS server and then another data flows
started to other server. In other words, he can also watch where this data
goes after DNS server. It is just a mapping without any need to have any
knowledge about the content of DNS server query request and response. Next
flow automatically reveal the content of this *encrypted* DNS messages...

The observer that can correlate data seems to be  so sophisticated and know
data mining approach and it is not hard for him to only map two flows with
the same initiated IP (just generalize it to all traffic...)

Only an example of what will be happening...Encrypted traffic from IP x goes
to public DNS server B. observer is only watching without active attack.
Next flow shows that there is traffic from IP x to website C.  the node with
IP x could encrypt data and sent it to DNSserver B. But couldn't hide the
content of data sent to DNS server B, even though encryption happened.
Because next flow with the same IP to website C exposed the content of last
flow initiated from the same IP. observer watched it without much efforts.
Now generalize it to all traffic flows that goes to a  public resolver and
then goes to somewhere else for all users...

If the target problem is to really hide the traffic and avoid the
correlations and avoid learning the pattern then I guess your approach is
not correct. You only need end-to-end tunneling  and not only encryption
because there is a need to all flows comes from IP addresses. The flows that
passed by observers' sniffers. 
In other words, network layer helps to leak information about flows....

Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Aug 2014 00:54:12 +0200

Just to be clear that you again, like my NAT example, do not misinterpret
what I wanted to say.. ......about IPv6.. I again talk about user and not
DNSSERVER. I mean the one who query  a DNS server with IPv6.... 
And only correct my last sentence... that there is a verb missing...

><snip.>You only
> need end-to-end tunneling  and not only encryption because there is a need
> to HIDE all flows comes from certain IP addresses. The flows that passed
by observers'
> sniffers.

<snip>

Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 19:49:21 -0400

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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Aug 2014 08:46:15 +0200

> This is the nub of your latest argument.

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

> 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