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 23:49 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 9A9BB1A0649 for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 16:49:29 -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 9u7Dt4ZktCKB for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 16:49:28 -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 354B91A0422 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 16:49:28 -0700 (PDT)
Received: from mx1.yitter.info (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 D3A6D8A031 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 23:49:26 +0000 (UTC)
Date: Wed, 20 Aug 2014 19:49:21 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-privacy@ietf.org
Message-ID: <20140820234921.GA2797@mx1.yitter.info>
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> <008101cfbcc6$09d9d110$1d8d7330$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <008101cfbcc6$09d9d110$1d8d7330$@rozanak.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/iNpUVOKbpAcoE2N_yd0cdSwA-p0
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 23:49:30 -0000

On Thu, Aug 21, 2014 at 12:28:15AM +0200, Hosnieh Rafiee wrote:
> knowledge about the content of DNS server query request and response. Next
> 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
ajs@anvilwalrusden.com