Delivery-Date: Mon, 04 Jan 2016 03:19:12 -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 8BACD1E0456;
	Mon,  4 Jan 2016 03:19:10 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B736538E21;
	Mon,  4 Jan 2016 08:19:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id F1CFA38E16
 for <tor-talk@lists.torproject.org>; Mon,  4 Jan 2016 08:19:00 +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 gjq5d_gHT7AF for <tor-talk@lists.torproject.org>;
 Mon,  4 Jan 2016 08:19:00 +0000 (UTC)
Received: from mail-lf0-f99.google.com (mail-lf0-f99.google.com
 [209.85.215.99])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id B062238E11
 for <tor-talk@lists.torproject.org>; Mon,  4 Jan 2016 08:19:00 +0000 (UTC)
Received: by mail-lf0-f99.google.com with SMTP id n70so7106126lfn.2
 for <tor-talk@lists.torproject.org>; Mon, 04 Jan 2016 00:19:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:in-reply-to:content-type:content-transfer-encoding;
 bh=9Qf3F1ZKaKkor07PX31BH1ZEPxMMl20mVXaCLTDBB5M=;
 b=KyJO+xSG+TErNRq7tsSGu/2dil2drm1s78e29wdo5d4D5uxwO+eLN5yQicLIM6vYhg
 PAJCmHYnfeh+OFs/7aYVQvwCLrFo6RgFarIs4OuUFuanqdz03u+GXeWGkyepHNDWsWXj
 Jmv+90tbXzyNlRnMvkxryoRd65tKlcG84ePX5dPY94x7ly9vP6+TpX0A2jCiZ5I7A2QV
 JpjMj7b3dTtED3WJKv89IxQOK9ctj/4uGQIwWIYsudysyqdBTctIkEZ3zgDb77dQytST
 htnZZThV9QvBZ8o5NiiF6E5hCny4eUwXBVcb4vO+7cAN82tysReD7ZA/QPjyE5UdK0rz
 Z46Q==
X-Gm-Message-State: ALoCoQmG6cA2IbBMYjFbNTI15YjziQ/hRDr4D5FBEY+jCgXFimWXx73O5mSioOmz47WSWo5NG3ZrnmzIMBJcY62rYdAF84wvNKRyTpI+pkH2TFFXMGCTH/w=
X-Received: by 10.194.205.103 with SMTP id lf7mr92955454wjc.147.1451895537222; 
 Mon, 04 Jan 2016 00:18:57 -0800 (PST)
Received: from apps.globaleaks.org (demo.globaleaks.org. [194.150.168.64])
 by smtp-relay.gmail.com with ESMTPS id hq3sm5406705wjb.4.2016.01.04.00.18.56
 for <tor-talk@lists.torproject.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 04 Jan 2016 00:18:57 -0800 (PST)
X-Relaying-Domain: apps.globaleaks.org
To: tor-talk@lists.torproject.org
References: <56880CDB.9070305@infosecurity.ch>
 <568834FB.6070008@torservers.net>
From: "Fabio Pietrosanti (naif) - lists" <lists@infosecurity.ch>
X-Enigmail-Draft-Status: N1110
Message-ID: <568A2AEB.1030609@infosecurity.ch>
Date: Mon, 4 Jan 2016 10:18:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
In-Reply-To: <568834FB.6070008@torservers.net>
Subject: Re: [tor-talk] On further minimizing harassment for Tor Exit Nodes
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>
MIME-Version: 1.0
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 1/2/16 10:37 PM, Moritz Bartl wrote:
>> We could trigger that if a Tor Exit operator would be able to have an
>> ExitPolicy that deny traffic going to the destination IPs of the country
>> where it's located, leading any kind of abuses to be originated because
>> of Tor Exit traffic flowing to a foreign country.
> 
> You can achieve something similar by placing your relay in a country
> other than your own, without the need of complicated rulesets.

Mmmmm ok, that's a very interesting input that trigger me to a couple of
consideration on the topic:


1st) Avoiding traffic going out to the same country where the Tor Exit
is located, is anyhow a protection measure for the Tor Relay operator

Assume the following matrix consideration:

a) I'm Italian, i run a Tor Exit in Germany, i prevent traffic from
going to Germany and Italy

b) I'm Italian, i run a Tor Exit in Germany, i prevent traffic from
going to Italy

c) I'm Italian, i run a Tor Exit in Germany, i prevent traffic from
going to Germany

d) I'm Italian, i run a Tor Exit in Germany, i do not apply any
country-specific blocks for outgoing traffic

From my own liability/resiliency issues against takedown
GermanyAutority->GermanyISP and legal takedown ItalianAutority->Myself
the option "a" would be the best one.

So the additional security requirements / resiliency being considered at
that point becomes two different:
Z) "placing the server outside the country"
Y) "avoid traffic destinated to the country where the server is located"

It's interesting because the AS-Aware routing would try to prevent "Y",
that also means that would be still leaving an improved legal capacity
action against Tor Relay operators's ISPs, because authorities would be
able to inquiry the ISPs directly, while giving the end-user a greater
benefit for privacy (less countries to be crossed for Tor Exit traffic).

2nd) Does TorServers-like organizations run most relay in their own country?

How TorServers organizations handle those kind of consideration?

- Do they usually prefer to keep Tor Relay in their own country, because
of easier handling of possible legal threat?
- Or do they prefer to place the Tor Relays in other countries because
of the additional international cooperation requirements, leading to
better informed decisions by authorities ?

Thinking about the "Onion Italia" setup those bring to a contradicting
balance between:
- the goal also to provide good exit traffic from Italy
- minimizing the liabilities by having Italia authorities uninformed
actions against us

For us placing servers outside Italy does not enable to fullfil the goal
to provide Tor Exit traffic in Italy, but placing it in Italy would
expose to the additional legal risks of uninformed decisions by law
enforcements officers (the "wakeup at 6.00am with someone knocking the
door").

So with a "Tor Exit Policy being geographical aware for allowance or
denial of specific country destinated traffic", could enable better
"granularity" in the balancing of liability
mitigation/resiliency/deployment, enabling to run an Italian legal
entity running Italian based servers c/o Italian ISPs, but add some
level of resiliency/protection against uninformed decisions by law
enforcements.


As a research topic, it would be interesting to make a matrix of the
different deployment scenarios with parameters such as:
- "Where are the persons responsible for the legal entity"
- "Where your legal entity is located"
- "Where the server is located"
- "Which country you allow traffic to go trough"
- "Routing of requests" in different scenarios

That things, together with some MLAT database of country-country
cooperation agreements/framework, feeded to a properly written algorithm
could suggest the top/most resilient "TorServers
Organizational/Legal/Technical/Architectural setups" ?

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

