Delivery-Date: Tue, 23 Jun 2015 09:54:49 -0400
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 D49E21E08BA;
	Tue, 23 Jun 2015 09:54:47 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 881603692D;
	Tue, 23 Jun 2015 13:54:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 94C1636920
 for <tor-talk@lists.torproject.org>; Tue, 23 Jun 2015 13:54:38 +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 6qU0eRqnnQ9p for <tor-talk@lists.torproject.org>;
 Tue, 23 Jun 2015 13:54:38 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil
 [IPv6:2001:480:20:118:118::211])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 6D2B335F96
 for <tor-talk@lists.torproject.org>; Tue, 23 Jun 2015 13:54:38 +0000 (UTC)
Received: from huygens.lan (vpn212046.nrl.navy.mil [132.250.212.46])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t5NDsXt4021453
 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 23 Jun 2015 09:54:35 -0400
Date: Tue, 23 Jun 2015 06:54:37 -0700
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <20150623135437.GC5248@huygens.lan>
References: <CAD2Ti2-xVw_W2YDqkdQHmcHyKBDQjfT5jvc-8m3EAU8UkqxrUA@mail.gmail.com>
 <55864B5C.6070509@cock.li>
 <20150621155532.GB1643@vpn212046.nrl.navy.mil>
 <CAD2Ti29UY7n=vwEPODtqzQoGsh7knEGSKz1bJqDb+nDF3YEaUQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAD2Ti29UY7n=vwEPODtqzQoGsh7knEGSKz1bJqDb+nDF3YEaUQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Subject: Re: [tor-talk] Matryoshka: Are TOR holes intentional?
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>

On Tue, Jun 23, 2015 at 12:06:41AM -0400, grarpamp wrote:
> Longer reply may come, but I think it is useful to again say
> that it may be that you must disassociate the classical "tor
> centric" idea of fill away from the idea of filling the "tor circuit".
> Of course any circuit level fill from end to end will still be visible.
> But if the network itself is doing its own node to node fill underneath,
> independant from whatever circuits ride on top, there may be
> your answer regard to the casual looker of GPA.

Even if, for the sake of argument, the padding node to node would work
perfectly for the security you want there, it would be irrelevant to
protecting correlation of client to destination. It is infeasible on
the network links that matter: those between the client and the
traffic-security network and those between the destination and the
network. The system is intended to provide protection of communication
with destinations that do not participate in its protocols. So even
ignoring who would pay for this overhead, the vast majority of
intended destinations won't participate.  And the vast majority of
clients could not afford to have always-on, full-length padding to
connect to the network. Nor would they like the performance of the
limit to that rate (e.g. no bursts above it).

aloha,
Paul
-- 
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

