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

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 20 August 2014 22:28 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069241A894C for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 15:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRScRvpk2xKj for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 15:28:50 -0700 (PDT)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091A11A8935 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 15:28:50 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id D7B855660140 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 22:28:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdQQpMDryfV1 for <dns-privacy@ietf.org>; Thu, 21 Aug 2014 00:28:18 +0200 (CEST)
Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 05908566013B for <dns-privacy@ietf.org>; Thu, 21 Aug 2014 00:28:17 +0200 (CEST)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: dns-privacy@ietf.org
References: <00ba01cfbbf9$d561f010$8025d030$@rozanak.com> <20140820143453.GD1065@mx1.yitter.info> <814D0BFB77D95844A01CA29B44CBF8A7A28554@lhreml513-mbb.china.huawei.com> <20140820152343.GH1065@mx1.yitter.info> <814D0BFB77D95844A01CA29B44CBF8A7A285FA@lhreml513-mbb.china.huawei.com> <20140820155522.GJ1065@mx1.yitter.info> <006201cfbcb3$d64e0940$82ea1bc0$@rozanak.com> <20140820212332.GG2464@crankycanuck.ca>
In-Reply-To: <20140820212332.GG2464@crankycanuck.ca>
Date: Thu, 21 Aug 2014 00:28:15 +0200
Message-ID: <008101cfbcc6$09d9d110$1d8d7330$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKUPlzldp8EhTskZiJwFszuzAaxyAJcgbntAd3fAtYBfgMRSgJ6DAKrAnqN6C8Co0HSZgIg9wccmdV1FQA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/WV9Jq4-uBiSFY53fxoCQ0dovrhA
Subject: Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 22:28:52 -0000

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

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