Delivery-Date: Wed, 28 Oct 2015 01:10:59 -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.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 5BD1E1E0ADC;
	Wed, 28 Oct 2015 01:10:57 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 397EA37CBC;
	Wed, 28 Oct 2015 05:10:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0012837CBE;
 Wed, 28 Oct 2015 05:10:43 +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 nEq3nr1x2f_C; Wed, 28 Oct 2015 05:10:43 +0000 (UTC)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com
 [IPv6:2607:f8b0:400e:c03::231])
 (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 ADAE037CBC;
 Wed, 28 Oct 2015 05:10:43 +0000 (UTC)
Received: by pasz6 with SMTP id z6so244664739pas.2;
 Tue, 27 Oct 2015 22:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=subject:mime-version:content-type:from:in-reply-to:date:cc
 :message-id:references:to;
 bh=vm8Eemau3XE5UGzrKdiW5Y+xCYByWlzr7BpCCLMx2T0=;
 b=nhm3j85bbkRdBeuJxnc3a2irCNCEj9BH9djCOLa++hMqVS5qqQW22G1V4QH0dJ/P//
 jvvWqNZngJG1FcpMtIhapoG4BalGaIWjWfWT3ElTNeh+lh675LJaykTMVuq3LqFeTuex
 Y0nCoAYdjd8KBz1YqBBt/WQ29eg9abgub7SO4E1kRXzUhH3///Fwy0zR/KeqLibvcstd
 zVNCh9rDri1cQaW/qRTcuVILZcaZeQdbjVrXFALbX87xhPocXF/764pQ1USMlf4Xsyvc
 jFDa/JmJ5/X+bwtPCzd2B7ibDUph7CTI0HIStAT8YUcZ3e6mXiW53a0n7TJs+6WsamBd
 R10g==
X-Received: by 10.66.222.232 with SMTP id qp8mr32445563pac.88.1446009041197;
 Tue, 27 Oct 2015 22:10:41 -0700 (PDT)
Received: from twilsonb-1-pt.tunnel.tserv15.lax1.ipv6.he.net
 (twilsonb-1-pt.tunnel.tserv15.lax1.ipv6.he.net. [2001:470:c:350::2])
 by smtp.gmail.com with ESMTPSA id ir4sm42661469pbb.93.2015.10.27.22.10.37
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 27 Oct 2015 22:10:40 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Tim Wilson-Brown - teor <teor2345@gmail.com>
In-Reply-To: <CADop2NFpPeS3t0_NjYryKXn3EhpBCw3xx5OgOS11P8isutV93Q@mail.gmail.com>
Date: Wed, 28 Oct 2015 16:10:29 +1100
Message-Id: <2B88B77C-6C27-4035-A712-F828C78C53DE@gmail.com>
References: <CAD2Ti29_BBCA9KspDU0uiCBRjvjCeFbc43Mii9X=r_0bosr=1A@mail.gmail.com>
 <CADop2NFpPeS3t0_NjYryKXn3EhpBCw3xx5OgOS11P8isutV93Q@mail.gmail.com>
To: tor-dev@lists.torproject.org
X-Mailer: Apple Mail (2.2104)
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] [tor-dev] Desired exit node diversity
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: multipart/mixed; boundary="===============5564917189357893985=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============5564917189357893985==
Content-Type: multipart/signed; boundary="Apple-Mail=_A59479AE-1F26-4559-90DE-AD95FB563D5F"; protocol="application/pgp-signature"; micalg=pgp-sha512


--Apple-Mail=_A59479AE-1F26-4559-90DE-AD95FB563D5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 28 Oct 2015, at 14:31, Virgil Griffith <i@virgil.gr> wrote:
>=20
> Instead of WOT, it seems more desirable, and better fit diversity, to =
have both your best friends and worst enemies on the same circuit. Ergo, =
minimizing chance of collaboration.

Like Tails' friends, foes, and neutral HTP pools=E2=80=A6
"any member in a one pool should be unlikely to share logs (or other =
identifying data), or to agree to send fake time information, with a =
member from the the other pools"
https://tails.boum.org/contribute/design/Time_syncing/#index4h2 =
<https://tails.boum.org/contribute/design/Time_syncing/#index4h2>

T

>=20
> -V
> On Mon, 26 Oct 2015 at 01:30 grarpamp <grarpamp@gmail.com =
<mailto:grarpamp@gmail.com>> wrote:
> On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had:
> > I agree with Roger that ideally all relays can be exits (and since
> > we're being ideal, we'll assume that 'exit' means to every port). =
And
> > the network location distribution of relays by bandwidth is
> > proportional to both the client destination selection over time and
> > general Internet traffic over time, which match each other since =
we're
> > being ideal, and also matter since we're using an ideal trust-aware =
path
> > selection algorithm. And network wide route selection is such that
> > there is no congestion (generalizing Roger's assumption of infinite
> > exit capacity).
>=20
> Guessing that... assuming you can ship and calculate all the relay
> data / DHT / weights / KEX / circuits / preferences without
> bogging down your network or cpu...
>=20
> More relays being exits yields higher maximum possible path diversity.
> More relays being exits yields higher potential aggregate throughput
> between the network and clearnet.
> More exits yields broader more complete location overlay relavent to
> users (more relays yields more guards), datacenteres, and clearnet
> services (though there's as yet no attempt to exit near a service
> unless done manually).
>=20
> However when subject to global passive adversary tapping
> lots of the fiber, and you turn up more relays as exits (which
> are also non-exit relays by nature), you're adding lots more
> unused bandwidth over the same current consumption, leading
> to lots of unused quiet portions of the network.
> Which seems a greater potential for the adversary to "look, user
> just shot a unique traffic pattern completely through the quiet
> zone, gotcha".
> Whereas when the network links are full with clocked traffic
> (and fill traffic if there would otherwise be slack space) that
> observation attack is hardly as possible, to relavently impossible.
>=20
> If true, it seems to me adding more [non] exits should be pegged to
> some metrics and solicited on need / planning rather than turning
> up 6000 exits all at once.
>=20
> > In our ongoing work on trust-aware path selection, we assume a trust
> > distribution that will be the default used by a Tor client if =
another
> > distribution is not specified. (Most users will not have a reasoned
> > understanding of who they actually need to worry most about, and =
even
> > if they somehow got that right would not have a good handle how that
> > adversary's resources are distributed.)  We call this adversary "The
> > Man", who is equally likely to be everywhere (each AS) on the
> > network. For relay adversaries, we assume that standing up and =
running
> > a relay has costs so weight a bit to make relays that have been =
around
> > a long time slightly more likely to be trusted.
>=20
> tor-relays had talk of individual humans keyparty signing their relays
> and including that WOT along with other trust and meta metrics
> in the consensus or other queryable datastore that could be used
> by the user to select preferred relay sets in whichever sensible or
> silly ways suited them.
>=20
> An adversary standing up relays has costs.
> Adversaries standing their human agents in public, even if
> their undercover is maintained, has additional costs and risks.
>=20
> > You
> > would then be faced with the political nightmare of issuing default
> > policies that tells users they should route with a weighting that =
says
> > country foo has an x percent chance of being your adversary, but
> > country bar has a y percent chance. (Likewise also have similar
> > statements that substitute 'large multinational corp.', 'major
> > criminal organization', 'specific big government agency that is
> > getting all the press lately' etc.  for "country" in the last
> > sentence.)
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D
> In a sense this is like the original 'valid' flag, which you got
> by mailing me and having me manually approve your relay (and without
> which you would never be used as the entry or exit point in a =
circuit).
> Periodically I wonder if we should go back to a design like that, =
where
> users won't pick exit relays that don't have the "socially connected"
> badge. Then I opt against wanting it, since I worry that we'd lose
> exactly the kind of diversity we need most, by cutting out the relays
> whose operators we don't know.
>=20
> But both sides of that are just guessing. Let's find out!
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
>=20
> These type of things may be better suited to a system
> where the users contribute their research and knowledge
> about the network into the network metadata db, and the
> users can query it to make their own decisions, follow
> other users prebuilt selection templates, or stick
> with the provided defaults.
> _______________________________________________
> tor-dev mailing list
> tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev =
<https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>
> _______________________________________________
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F


--Apple-Mail=_A59479AE-1F26-4559-90DE-AD95FB563D5F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWMFjHAAoJEEUMun+WjwlL1G0QAI/tjnSJVoT0MiEL/lWq3/tl
oljVg9W9eaH9O2SG2tBS9Sdl1aDqA5aK6nudAWhNrI2unKifD52UZKWszH1UfHFv
nkfyrjaCZpU7f9NTeFXJzDgBJlrCZT1ooof3nSF2SoexF67zkq64hT0A7IapsLSD
r0ds7DyDoaUERt2acZ8n3r9xBU7Vu8jY9y20XWAPEwdWniWQqHmzcM3CYFWN/ufq
OSlCEcA1hCyAwLEA/8HBqOUy19VwHTFHnYRVcigk/IdlXUm0Em5VO0gljIhI7drv
oiWMBIcjGBP2wqEa8LympTX2OTrlEhQJy6KEdrMm0DVHNfsMIM8j+vNpeHyENq/r
U0WVD+3QV9ZrChSvqtOKYQEJTLCg1bB6Q6zhMvyETYJ0ei6YdEJCpOiyMctZ/npW
YrHy8ZnmoBImDCycTWhxq0UhCs8fIWd2l00xGrBbgjYSfhTyc7pIqghUxWZotwpJ
vYZoFK7sXUwF0T6U6iqAIGfZOfPUgGoTELkR4VnIqeH6BWqqnYLoBBuLshK+eFac
3361CkI+l+YoOM0ohehJVdzzbSFmRUH5U71p255p+UFHkeFihYH1+rVKKZ3NY0Bw
uwrXPrxxT21QKbHdP8qmb5mNlWdv7ewUp2g+4Tm9TGvMA4lHmSwr6x9M1VwGXWQx
3cPmy3re9I94cqR1llx8
=aOCN
-----END PGP SIGNATURE-----

--Apple-Mail=_A59479AE-1F26-4559-90DE-AD95FB563D5F--

--===============5564917189357893985==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5564917189357893985==--

