[tor-dev] 0.2.8 triage at dev meeting!

[Isabela]

Hello everyone!

We are planing on doing a triage session for 0.2.8 release in Berlin!
Below is some guidance of what you can do to prepare for that, also what
you can do if you are planning on being there but want to help build the
release.

Who should participate? Core Tor developers, obfuscation developers, Tor
Browser developers, Hidden Services developers, and of course anyone else 

To help with the triage we are asking everyone to add the following
information to tickets you think should be part of 0.2.8

  * keyword field: 0.2.8.x-triage

  * Size field: an estimation of how long you think it will take to get
it done (not counting review time, just execution):
* small < 1 day
* medium < 1 week
* large > 1 week

  * Priority field:
* blocker
* critical
* major
* normal
* minor
* trivial

  * Sponsor field: if it's related to a sponsor deliverable

For 0.2.7 triage we did a few rounds until we ended with a good chunk of
work for the release. The release is coming out this month and here is
some numbers related to it if you would like to use as a reference:
https://storm.torproject.org/shared/TLgTuwGNswrIbfhj9NUctPKj6iG9V7KGHpwy7yzbYk9

I will send more updates on how this first triage session will be done
in Berlin and how we will get remote folks to participate. Also, this
does not mean what we do in Berlin is final, things can be refined after
too.

Cheers,
Isabela

-- 
PM at TorProject.org
gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1  B298 3224 4994 1506 4C7B
@isa




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Virgil Griffith]

Apologies for quick post.

If we want to a socially connected link, seems we can use the same
infrastructure for doing keysignings parties but we just use relay public
keys. That seems a nice distributed way of doing this.
On Thu, 24 Sep 2015 at 13:42 Virgil Griffith  wrote:

> Can we not use the argument "anonymity requires diverse company" on both
> sides? For whole rational actors it seems like this should work. Tor
> "exploits the military" into lending cover to activist groups, which they
> would presumably support.
>
> This may be too naive a view of the situation.
>
> Re: socially connected. That's interesting. I'll see what I can do. Chat
> more in Berlin.
>
> -V
> On Thu, 24 Sep 2015 at 13:19 Roger Dingledine  wrote:
>
>> On Wed, Sep 23, 2015 at 06:18:58AM +, Virgil Griffith wrote:
>> > Exit nodes seem a nice place to start concretizing what's meant when we
>> say
>> > we want relay diversity. Comments immensely appreciated because as-is I
>> > don't know the answers to these questions.
>>
>> Hi Virgil,
>>
>> I've been pondering the opposite of this topic, after looking at the
>> recent tor-relays thread about some ISP not wanting to let somebody
>> host an exit relay because they figure a lot of the Tor network is
>> run by government agencies. My usual answer to that concern is "no, we
>> *know* the operators of more than half the capacity in the Tor network,
>> so this cannot be the case". And I think this is increasingly true in
>> the era of activist non-profits that run relays -- Germany's got one,
>> and so do the US, the Netherlands, Sweden, France, Luxembourg, etc etc.
>>
>> But it would be neat to have a mechanism for learning whether this is
>> actually true, and (whatever the current situation) how it's changing.
>>
>> The tie-in to Roster would be some sort of "socially connected" badge,
>> which your relay gets because you're sufficiently tied into the Tor
>> relay operator community.
>>
>> And then we'd have something concrete to point to for backing up, or
>> disputing, the claim that we know a significant fraction of the network.
>>
>> Of course, the details of when to assign the badge will be tricky and
>> critical: too loose and you undermine the trust in it (it only takes a
>> few "omg the kgb runs a relay and look it's got the badge" cases to make
>> the news), but too strict and you undercount the social connectedness.
>>
>> 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.
>>
>> But both sides of that are just guessing. Let's find out!
>>
>> --Roger
>>
>> ___
>> tor-dev mailing list
>> tor-dev@lists.torproject.org
>> 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

Re: [tor-dev] Desired exit node diversity

[Griffin]

Virgil Griffith wrote:
>  Tor "exploits the military" into lending cover to activist groups,
> which they would presumably support.
> This may be too naive a view of the situation.

  Exploit is definitely the wrong word here.  Different people who
disagree about {policy|topic|whatever} can all see the value of
anonymity, without viewing it as ab/using the other contributors.

  More relays are always good, but don't necessarily counter the
occasional fatalist opinion 'surely n relays are bad and surely n
represents enough to de-anonymize me no matter what, so why bother' [0].
Ongoing research does a lot of good here, but some people will never be
swayed.

~Griffin

[0] "Is your relay hiding BOLSHEVIKS?"

> Re: socially connected. That's interesting. I'll see what I can do.
> Chat more in Berlin.
> 
> -V
> On Thu, 24 Sep 2015 at 13:19 Roger Dingledine  wrote:
> 
> On Wed, Sep 23, 2015 at 06:18:58AM +, Virgil Griffith
> wrote:
> > Exit nodes seem a nice place to start concretizing what's
> meant when we say
> > we want relay diversity. Comments immensely appreciated
> because as-is I
> > don't know the answers to these questions.
> 
> Hi Virgil,
> 
> I've been pondering the opposite of this topic, after looking
> at the
> recent tor-relays thread about some ISP not wanting to let
> somebody
> host an exit relay because they figure a lot of the Tor
> network is
> run by government agencies. My usual answer to that concern is
> "no, we
> *know* the operators of more than half the capacity in the Tor
> network,
> so this cannot be the case". And I think this is increasingly
> true in
> the era of activist non-profits that run relays -- Germany's
> got one,
> and so do the US, the Netherlands, Sweden, France, Luxembourg,
> etc etc.
> 
> But it would be neat to have a mechanism for learning whether
> this is
> actually true, and (whatever the current situation) how it's
> changing.
> 
> The tie-in to Roster would be some sort of "socially
> connected" badge,
> which your relay gets because you're sufficiently tied into
> the Tor
> relay operator community.
> 
> And then we'd have something concrete to point to for backing
> up, or
> disputing, the claim that we know a significant fraction of
> the network.
> 
> Of course, the details of when to assign the badge will be
> tricky and
> critical: too loose and you undermine the trust in it (it only
> takes a
> few "omg the kgb runs a relay and look it's got the badge"
> cases to make
> the news), but too strict and you undercount the social
> connectedness.
> 
> 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.
> 
> But both sides of that are just guessing. Let's find out!
> 
> --Roger
> 
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> 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

-- 
“Intelligence without ambition is a bird without wings.”
― Salvador Dalí


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Thomas White]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Could we perhaps expand the contact information field in some way? One
thing I was pondering a while ago was a social contact, not just an
email address. I raised a very brief point about this with Virgil in
Paris last year, but I think I made it very poorly at the time as I
just come up with it on the spot.

To assign an email address is good for email communications and using
PGP and so forth, but also allowing another handle such as a Twitter
username would be a way to create further credibility of diversity.
For example, my following on Twitter is quite diverse and it would be
hard to argue I was a government proxy or so on. If many operators
have Twitter handles where the information and identity is public
anyway, having a second option to tie into those social parameters
would be more transparent in the people running those relays if they
chose to be. For example, I have no problem in being open on some of
the projects I am working on, and I'm sure moving into a social sphere
could have a positive effect on Tor in general in terms of trust.

For example, let's say the contact box lacks an email, we could see if
there was a way for reaching out to people via Twitter to let them
know a relay is outdated instead of private email reminders.

Anyway I am rambling on a bit there, but my point is getting people to
use not just email, but also tie into a twitter account or something
of that nature would make it clearer that Tor is not run almost
exclusively by the military or whatever, since that kind of open data
with aliases and Twitter feeds connected to the relay ownership is
researchable if people, like Transparency Toolkit, wanted to "check us
out" so to speak. To verify the data, we could make Roster have a
small verification step, just a "tweet this code to verify this is
your account" and then Roster can store the URL to this tweet to
maintain an independent proof that alias controls which relay, similar
to how Keybase does it.

T

On 24/09/2015 06:18, Roger Dingledine wrote:
> On Wed, Sep 23, 2015 at 06:18:58AM +, Virgil Griffith wrote:
>> Exit nodes seem a nice place to start concretizing what's meant
>> when we say we want relay diversity. Comments immensely
>> appreciated because as-is I don't know the answers to these
>> questions.
> 
> Hi Virgil,
> 
> I've been pondering the opposite of this topic, after looking at
> the recent tor-relays thread about some ISP not wanting to let
> somebody host an exit relay because they figure a lot of the Tor
> network is run by government agencies. My usual answer to that
> concern is "no, we *know* the operators of more than half the
> capacity in the Tor network, so this cannot be the case". And I
> think this is increasingly true in the era of activist non-profits
> that run relays -- Germany's got one, and so do the US, the
> Netherlands, Sweden, France, Luxembourg, etc etc.
> 
> But it would be neat to have a mechanism for learning whether this
> is actually true, and (whatever the current situation) how it's
> changing.
> 
> The tie-in to Roster would be some sort of "socially connected"
> badge, which your relay gets because you're sufficiently tied into
> the Tor relay operator community.
> 
> And then we'd have something concrete to point to for backing up,
> or disputing, the claim that we know a significant fraction of the
> network.
> 
> Of course, the details of when to assign the badge will be tricky
> and critical: too loose and you undermine the trust in it (it only
> takes a few "omg the kgb runs a relay and look it's got the badge"
> cases to make the news), but too strict and you undercount the
> social connectedness.
> 
> 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.
> 
> But both sides of that are just guessing. Let's find out!
> 
> --Roger
> 
> ___ tor-dev mailing
> list tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJWA/Y2AAoJEIC+hZxcLl/kVCQP/RwqPjg3H1XnX+XqmoLTG72H
9FnEATk/1bF6oHJwF7IiklOjpuHFzdEzAorp7oUbCfW1A8pIS03zUW9cb2c37+id
UzktDiKKy0MmxWOgUs2Lx2V5x5wxx+tu8l4FT1sc4P8fFPQVHiNf20+oy1uU+4DY
TMlppgQjq6qD0wc1xt2hQJKjSK8T1VdAvkQlDNr8i9GyR74B5aKfOazl6wNtIZa5
nJbe4MkhmDlioTl/lbs4uO1SLWgvVqf0iIV7F6Xn5tPNvIX3pdeZpw2beZr/2STk
GoVWtpJOpHU9WWRaY6tMbSL4qcMUJkGHWp6JNYYdgHt3AAZNxrH8fbRm3qY8NdpQ
iDkN61jsWpBwYngCNGeOTo/c4dPNaSimyKegT5w+9MDr+00sePzqT0I1aE9amy47

Re: [tor-dev] 0.2.8 triage at dev meeting!

[Nick Mathewson]

On Thu, Sep 24, 2015 at 7:49 AM, Isabela  wrote:
> Hello everyone!
>
> We are planing on doing a triage session for 0.2.8 release in Berlin!
> Below is some guidance of what you can do to prepare for that, also what
> you can do if you are planning on being there but want to help build the
> release.
>
> Who should participate? Core Tor developers, obfuscation developers, Tor
> Browser developers, Hidden Services developers, and of course anyone else
>
> To help with the triage we are asking everyone to add the following
> information to tickets you think should be part of 0.2.8
>
>   * keyword field: 0.2.8.x-triage

We usually use "028-triage" here.  (No periods.)  Feel free to use
either spelling. I'll do a batch-modify to condense them into one.

>   * Size field: an estimation of how long you think it will take to get
> it done (not counting review time, just execution):
> * small < 1 day
> * medium < 1 week
> * large > 1 week
>
>   * Priority field:
> * blocker
> * critical
> * major
> * normal
> * minor
> * trivial
>
>   * Sponsor field: if it's related to a sponsor deliverable
>
> For 0.2.7 triage we did a few rounds until we ended with a good chunk of
> work for the release. The release is coming out this month and here is
> some numbers related to it if you would like to use as a reference:
> https://storm.torproject.org/shared/TLgTuwGNswrIbfhj9NUctPKj6iG9V7KGHpwy7yzbYk9
>
> I will send more updates on how this first triage session will be done
> in Berlin and how we will get remote folks to participate. Also, this
> does not mean what we do in Berlin is final, things can be refined after
> too.
>

Sounds great!  Thanks, Isabela!

-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Simplifying load balancing by removing Guard+Exit?

[Mike Perry]

Hey all,

I am playing with the load balancing equations in 3.8.3 in dir-spec.txt
(https://gitweb.torproject.org/torspec.git/tree//dir-spec.txt#n2454) in
order to account for padding, hidden/onion services, and directory
traffic, and I've noticed that the fact that nodes can be both Exits and
Guards not only vastly complicates the current equations, but will make
any attempt at accounting for this additional overhead nearly
impossible.

If you've previously tried to understand the current load balancing
equations, or wondered why they have 3 major sub-cases and roughly 9
sub-cases, this is entirely to account for Guard+Exit nodes, and to
handle relative scarcity of pure Guard and pure Exit nodes in various
conditions.

Removing the Guard+Exit ('D') nodes makes all of those cases condense to
one single, simple set of solutions:

⎧ E + G + M   E + G + M   2⋅E - M - G   2⋅G - M - E ⎫
⎨Wee: ─, Wgg: ─, Wme: ───, Wmg: ⎬
⎩3⋅E 3⋅G  3⋅E   3⋅G ⎭

No missing constraints, no sub-cases, no boundary conditions. Easy to
reason about. Easy to intuitively convince yourself that the solutions
are correct.


What I want to do is add two variables to the consensus that allow us to
specify expected (or measured) overhead at Guard nodes (G_o) and at
Middle nodes (M_o). These two variables would represent the sum of
padding, directory overhead, and hidden service traffic experienced by
Guard and Middle nodes, respectively. If we ignore Guard+Exit nodes,
this makes the load balancing equations become:

 (1-G_o)*Wgg*G == (1-M_o)*(M + Wme*E + Wmg*G) # Guard bw == middle bw
 (1-G_o)*Wgg*G == Wee*E   # Guard bw == exit bw 
 Wmg*G + Wgg*G == G   # Guards can be middles or Guards
 Wme*E + Wee*E == E   # Exits can be middles or Exits

These solutions are a bit longer so I won't paste them here, but they
are still reasonable if we ditch the Guard+Exit idea. They can be
simplified even further by using a similar approach as the GuardFraction
idea from Proposal 236 (Section 1.3): We can simply adjust each Guard's
bandwidth by G_o either before solving the equations, or by adjusting
Wgg and Wmg after the solution, then we only need to include the (1-M_o)
factor in the equations themselves.

We can't really do this simplification if we keep Guard+Exit, because of
the interplay between Exit and Guard weights in the system of equations
and cases.

Additionally, if we keep Guard+Exit, the solutions literally consume an
entire page of text to represent symbolically, and the sub-cases become
even more complicated to evaluate and check for proper bounds and
correctness. In fact, George has already run into such edge cases while
trying to implement Proposal 236 (See
https://trac.torproject.org/projects/tor/ticket/16255).


Moreover, I've been thinking about the surveillance incentives for
Guard+Exit nodes, and I actually think it is a net risk to the network
for nodes to be both Guards and Exits. It's easy to find an excuse to
watch an Exit node. If anything bad ever happens from an Exit, you may
be able to convince someone to let you keep an eye on it** "just in
case".  A Guard-only node shouldn't cause anybody any problems, though,
and should be much harder to justify monitoring.

So this means that Guard+Exit nodes allow an adversary to justify
monitoring large portions of both the entry and exit traffic of the
network without any strange/technical/esoteric arguments about the need
to perform complicated statistical attacks with questionable accuracy
and high collateral damage, and instead force them to justify their
monitoring another way.

I also hear from large node operators that it is still the Exit flag
that causes their nodes to really become overloaded, so if that's
actually true, then it's likely that Exit nodes make poor Guards anyway,
especially if Exit bandwidth is scarce (which it often is).


So, what do people think? Does anyone violently disagree with removing
the Guard flag from Guard+Exit nodes?


** I used to run an Exit node, and my lawyer at the time was told
exactly this at one point during a police visit about a nonsensical bomb
threat to some 4chan equivalent. He was specifically told "We will be
monitoring this node from now on" by one of the visiting officers. I was
unable to ever discover what that actually meant, and the EFF
unfortunately did not feel it was worth pursuing to help me find out. It
may have been a scare tactic, but it could just as easily have not been,
and for all I know they may have been actually able to convince a judge
to let them do this.


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Tim Wilson-Brown - teor]

> On 24 Sep 2015, at 23:10, Thomas White  wrote:
> 
> Signed PGP part
> Could we perhaps expand the contact information field in some way? One
> thing I was pondering a while ago was a social contact, not just an
> email address. I raised a very brief point about this with Virgil in
> Paris last year, but I think I made it very poorly at the time as I
> just come up with it on the spot.
> 
> To assign an email address is good for email communications and using
> PGP and so forth, but also allowing another handle such as a Twitter
> username would be a way to create further credibility of diversity.
> For example, my following on Twitter is quite diverse and it would be
> hard to argue I was a government proxy or so on. If many operators
> have Twitter handles where the information and identity is public
> anyway, having a second option to tie into those social parameters
> would be more transparent in the people running those relays if they
> chose to be. For example, I have no problem in being open on some of
> the projects I am working on, and I'm sure moving into a social sphere
> could have a positive effect on Tor in general in terms of trust.
> 
> For example, let's say the contact box lacks an email, we could see if
> there was a way for reaching out to people via Twitter to let them
> know a relay is outdated instead of private email reminders.
> 
> Anyway I am rambling on a bit there, but my point is getting people to
> use not just email, but also tie into a twitter account or something
> of that nature would make it clearer that Tor is not run almost
> exclusively by the military or whatever, since that kind of open data
> with aliases and Twitter feeds connected to the relay ownership is
> researchable if people, like Transparency Toolkit, wanted to "check us
> out" so to speak. To verify the data, we could make Roster have a
> small verification step, just a "tweet this code to verify this is
> your account" and then Roster can store the URL to this tweet to
> maintain an independent proof that alias controls which relay, similar
> to how Keybase does it.

It would be great to do this in a way that’s independent of social media 
platform.

Many social media platforms have been invented and gone under in the time the 
Tor Network has been running.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Simplifying load balancing by removing Guard+Exit?

[Tim Wilson-Brown - teor]

> On 25 Sep 2015, at 01:33, Mike Perry  wrote:
> 
> I also hear from large node operators that it is still the Exit flag
> that causes their nodes to really become overloaded, so if that's
> actually true, then it's likely that Exit nodes make poor Guards anyway,
> especially if Exit bandwidth is scarce (which it often is).
> 
> 
> So, what do people think? Does anyone violently disagree with removing
> the Guard flag from Guard+Exit nodes?

I wondered how many guards would we have before and after this change:

1021 Exits

1725 Guards
* 412 Guards that are Exits
* 1313 Guards that aren’t Exits

This would be a 24% decrease in the number of Guards, which seems ok, 
particularly if they’re not good at being guards anyway.
(Counts from the 2015-09-24 21:00:00 microdesc consensus in my local Tor 
Browser data folder.)

Would we also want to disable the DirPort on Exits? Or is that a small amount 
of extra load?
Similarly, what about the HSDir flag?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev