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

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 20 August 2014 21:23 UTC

Return-Path: <ajs@anvilwalrusden.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 CD0E01A0B7B for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 14:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
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 TvFL_6y4PwhH for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 14:23:38 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E281A0097 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 14:23:38 -0700 (PDT)
Received: from crankycanuck.ca (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 678A48A031 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 21:23:37 +0000 (UTC)
Date: Wed, 20 Aug 2014 17:23:32 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-privacy@ietf.org
Message-ID: <20140820212332.GG2464@crankycanuck.ca>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <006201cfbcb3$d64e0940$82ea1bc0$@rozanak.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/hKgtNAHGKpUXgHxONCu6qUGtsEw
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 21:23:39 -0000

On Wed, Aug 20, 2014 at 10:17:57PM +0200, Hosnieh Rafiee wrote:
> 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,

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

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com