Delivery-Date: Sat, 30 Jan 2016 22:47:58 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 80A651E0422;
	Sat, 30 Jan 2016 22:47:56 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 780743920D;
	Sun, 31 Jan 2016 03:47:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4F969391A1
 for <tor-talk@lists.torproject.org>; Sun, 31 Jan 2016 03:47:47 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cRePBPmNquhW for <tor-talk@lists.torproject.org>;
 Sun, 31 Jan 2016 03:47:47 +0000 (UTC)
Received: from gombert.agol.dk (gombert.agol.dk [212.60.120.178])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 1EBFA391A0
 for <tor-talk@lists.torproject.org>; Sun, 31 Jan 2016 03:47:46 +0000 (UTC)
Received: by gombert.agol.dk with esmtpsa 
 (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84 #2 (EximConfig
 2.5))
 id 1aPizG-00067N-6w  by authid <elgaard>  with auth_server_plain 
 for <tor-talk@lists.torproject.org>; Sun, 31 Jan 2016 04:47:42 +0100
To: tor-talk@lists.torproject.org
References: <56AB8BD7.2090205@agol.dk> <56AD50E4.4070404@gmail.com>
From: Niels Elgaard Larsen <elgaard@agol.dk>
X-Enigmail-Draft-Status: N1110
Message-ID: <56AD83D4.3090107@agol.dk>
Date: Sun, 31 Jan 2016 04:47:32 +0100
MIME-Version: 1.0
In-Reply-To: <56AD50E4.4070404@gmail.com>
X-EximConfig: v2.5 on gombert.agol.dk (http://www.jcdigita.com/eximconfig)
Subject: Re: [tor-talk] Danish data retention on steroids
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>



aka:
> Niels Elgaard Larsen:
>> * Session volume (number of bytes)
> 
>> 1. Tor would kill this right at the entry-node? Even a user fired up
>> TorBrowser, typed in http://example.com/foo.mp4, watched the video and
>> closed the brower, there would be enough negoitiation to obfuscate the
>> bytecount?
>>
> 
> I assume "session volume" is the size of payload data transfered in a
> single TCP session.

Yes.

> If a Danish Tor user visited a Danish website affected and the website
> used non-multiplex http (everything before http/2 and SPDY) there would
> be 30 different TCP sessions for all those pictures, scripts, 3rd party
> tracker elements, etc on the website.


I just checked the front page of politiken.dk, one of the major Danish
newspapers. Without an adblocker it is 202 request to 7 different
domains. So even with HTTP/2 there would be some quite detailed logging.

> So in the data retention database
> there will be a very fine grained and timestamped traffic log of this
> particular site visit, useable for traffic correlation attacks. The
> situation gets even worse if the website uses some periodic push/pull
> system like for example a twitter feed, creating and closing TCP
> connections every few seconds.

Indeed. While I was typing the above paragraph there was three more
requests to https://ping.chartbeat.net/ on the Politiken page.

> Lots of data over one single persistent TCP connection = only one entry
> in data retention database = not useful for deanonymizing Tor users.
> Lots of data over many short lived TCP connections over a long period of
> time = many fine grained entries in data retention database = useful for
> deanonymizing Tor users.


Yes. Unless it is a very popular site, used by many Tor users at the
same time.

> It should also be taken into account the goverment could force the ISP
> to terminate TCP connections every few seconds to increase the amount of
> logs created.

Not so likely. This is a proposed law that the ISP's are fighting. They
would not do more than required by the law. The Danish government cannot
force ISP's to do things like that.  But of course what matters is not
my ISP but the ISP behind the site I am connected to. And one or two
ISP's might be willing to cooperate.


-- 
Niels Elgaard Larsen
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

