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
- [dns-privacy] New draft on encrypting the stub-to… Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Paul Wouters
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Joe Abley
- Re: [dns-privacy] New draft on encrypting the stu… Paul Wouters
- Re: [dns-privacy] New draft on encrypting the stu… Hosnieh Rafiee
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Carsten Strotmann
- Re: [dns-privacy] New draft on encrypting the stu… 神明達哉
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Jacob Appelbaum
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Paul Wouters
- Re: [dns-privacy] New draft on encrypting the stu… Jacob Appelbaum
- Re: [dns-privacy] New draft on encrypting the stu… Jacob Appelbaum
- Re: [dns-privacy] New draft on encrypting the stu… Paul Wouters
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Carsten Strotmann
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Jacob Appelbaum
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Andrew Sullivan
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Jacob Appelbaum
- Re: [dns-privacy] New draft on encrypting the stu… Stephane Bortzmeyer
- Re: [dns-privacy] New draft on encrypting the stu… 神明達哉
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Andrew Sullivan
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Hosnieh Rafiee
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Andrew Sullivan
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Jacob Appelbaum
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Paul Wouters
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Jacob Appelbaum
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Paul Hoffman
- [dns-privacy] draft-hoffman-dns-tls-stub-01 posted Paul Hoffman
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… David Ulevitch
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Andrew Sullivan
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Andrew Sullivan
- Re: [dns-privacy] [SPAM] Re: New draft on encrypt… Hosnieh Rafiee
- Re: [dns-privacy] New draft on encrypting the stu… Wes Hardaker
- [dns-privacy] Authenticating the resolver Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… Mark Andrews
- Re: [dns-privacy] New draft on encrypting the stu… Wes Hardaker
- Re: [dns-privacy] Authenticating the resolver Wes Hardaker
- Re: [dns-privacy] Authenticating the resolver Paul Hoffman
- Re: [dns-privacy] New draft on encrypting the stu… John Heidemann
- Re: [dns-privacy] New draft on encrypting the stu… Phillip Hallam-Baker