Delivery-Date: Mon, 12 Oct 2015 21:21:54 -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 80A5C1E0C76;
	Mon, 12 Oct 2015 21:21:52 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5EDD921BFB;
	Tue, 13 Oct 2015 01:21:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A2E9F380E8
 for <tor-talk@lists.torproject.org>; Tue, 13 Oct 2015 01:21:44 +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 WOji3LujtT3L for <tor-talk@lists.torproject.org>;
 Tue, 13 Oct 2015 01:21:44 +0000 (UTC)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 7170137E7F
 for <tor-talk@lists.torproject.org>; Tue, 13 Oct 2015 01:21:44 +0000 (UTC)
Received: from localhost ([194.150.168.95]) by mail.gmx.com (mrgmx002) with
 ESMTPSA (Nemesis) id 0M3RZI-1acfv22XcO-00r1XR for
 <tor-talk@lists.torproject.org>; Tue, 13 Oct 2015 03:21:41 +0200
Date: Tue, 13 Oct 2015 03:20:57 +0200
From: "sh-expires-12-2015@quantentunnel.de"
 <sh-expires-12-2015@quantentunnel.de>
To: tor-talk@lists.torproject.org
Message-ID: <20151013012057.GD2119@localhost.localdomain>
References: <6.2.5.6.2.20151011115307.0711bbc0@binnacle.cx>
 <CAD2Ti2-KsGjF5F9REyh2WHJtDfuC+dQoqa4n4fY05wfy0sXv+A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAD2Ti2-KsGjF5F9REyh2WHJtDfuC+dQoqa4n4fY05wfy0sXv+A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Provags-ID: V03:K0:ejOWoBUaQdTC34eHc7iu1foDtIBQC956q7z/cqmsubWgaNnWkJB
 SrRN17ts64EvFAl0Sjo++yPSAxXYnNZaE6PzjVHRj/XCUL5Zw7xGorj+RHMaYlGJTVoKz/z
 yOFjnW+KLZPzWMB3SNKoKw2kV09vXHX/M2PfmSb0CKotjMUusrwxtcUjF4LPeExy4ytm6Oe
 0O93OzcN2u377vkNbYeIw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:wlwJGJgzDz0=:ntEy6/ZX6IIqwfPrWS3X1A
 CFzfeU2MfPluFmpzntvB24z5mZa5vxGS+X2AxIuoi5tBjsH/5C1CGbsqmwuTneuw5Zjj5C+rX
 zfvGDLmB2spXiZCSiPmF5yjbQcfyJshdAYHHlTyge09SOfwB7dQoHIb71KdEZP47cjd/ZiD8N
 lrkXrtdHK+AOaRJeSHgGenvxDpLRyV7RniGVH8EbLseeroydIZw7+HHx316Mm+oKxiClgP4q/
 t3vVH8kwyqu1U11FQFqmBRRrTb6ukygUndwhVTjyyMtp9myu4uPxcgKqUFK2r2d3hBSoQjRVU
 H0IJQFJkv7WASrguDp62VZS1HF8qpboSbMcgqmHWgOtOE6CEECBd6gzlMVVgwlZf1uhoG5RT7
 zY8kxo0wC1q1d+rOo9fZmIry61Ud/orZ3m7VCJpbE0rnS84LIJ5cWhwyCOQNuxCOpDskJSYTK
 828VY5jn68LVFiyXPcCJuj3G1cXobCFtkCb6BL+HBeT3ieKB4g7Nv2zhpV8H6MfIBYlm/UwIL
 WD9LrC9T6arqTH0WrDZDJdEoH3IPsOfzelGg8Vh5JbDsXZDUZ5w5rcW/b9iVfgSFoQ28v0trk
 jwkOhTfE+mqFw9LHSnZmwpab+5zx7VCGbIrM1twNDA5YgymN8WXdwpGi7tXnSlEFc0Of/KqzY
 PpWm6A7fbvbid/44aDv9JeGICN3ZBrnNTUCHd+B7g2RqKi9C+qn3Gzotfp/ZhFHHNpCVpwgCb
 DiFETdthpDuqy5LjyF/lOGFU+jje8yuhmQJAEfx7Sbalyd8t9tS1jtXUKxU=
Subject: [tor-talk] Mulihomed flag for nodes (from Re: why are some exit IPs
 missing from Exit IP DB?)
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 Sun, Oct 11, 2015 at 01:12:53PM -0400, grarpamp wrote:
> No, I'd consider it a technique to avoid having
> your exit put on braindead tor-hating consensus
> scraping blacklists... a feature not a bug... with

Tor users aren't entitled to special treatment,
and another false conclusion one could draw from
that is one is being MITMed. If you get the
impression a service like Tor isn't honest to
you, you may consider it open the usual FUD
from parties who don't like Tor.

Honestly, you don't want that.

Since Tor is available to everyone, it shoud be
easy to not to unwillingly participate too. The
rationale behind this, is for example a Site offers
services that stores user data and ip-addresses,
that information could be made or become available 
to 3rd parties.

It could be a site-ops choice, not to allow users
to use his services, since it may compromise them.

Ever thought of that?

> the great side effect that such exits are usable to
> circumvent similar braindead / hating censorship
> directed at tor users.

Have you ever considered, that people who
operate hidden services for websites, like to redirect
people to said hidden services instead of relying
on exits? How can we do that without relying on tors
internal information or query other services?

> Exonerator is for operators, that's their choice there.

Exonerator is available to everyone, and some assumptions
Karsten has, like storing IPs forever aren't even in the
best interests of all operators. And I feel the tor-project
should be much more open and aware of possible impacts and
sideeffects from all the information it stores longterm.

Sorry, if that sounds scary, but some relay operators
I met the this year hat quite a negative relay experience.

> I'd rather add a blurb on check.tpo to hit newnym
> and check again if user has reason to believe they're
> using tor than start booting relays because of this.
> (Or "fixing" exit DB / check.tpo by scanning).

The consensus enables us to build circuits, and the Exit
_*FLAG*_ that this node could be an endpoint for a circuit.

Basically, were a packet leaves isn't relevant to operate,
since it uses circuits and nodes participating doesn't need
to know. ;)

I am currently wrapping my head around this, trying
to figure out if it makes correlation attacks easier
or MITMing and inserting convert channels between
arbitrary nodes harder.

Any other conclusion we draw from that, shows a lack of
understanding in either the consensus or Tor.

While we are at it, I consider having the exit ip for
multihomed nodes in the consensus beneficary. If
you like to start including additional information into
the consensus consider the AS too.

The data is available form the RIRs, I am using it with
a Tor monitor, that isn't libre and I am not sure how the
RIRs would like to have their services put under load.

Anyway, I am moving this to tor-talk with the intention 
to discuss, at least, a multihomed flag.

Could be provided like the Family-Information.

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

