[tor-dev] tor-roster's geo diversity badge and self-ref relays

2015-09-12 Thread nusenu 
Hi,

tor-roster has a badge for in-family geo diversity:

"Geo Diversity in Relays (Number of countries / Number of relays >= 0.5)"

Do you consider in-family diversity so important - even though all of
them are run by a single entity anyway?

I'd consider the tor network's overall diversity far more important than
in-family diversity because clients won't use more than one relay of a
given family anyway.

How about having a badge for tor network wide diversity?
Something like:

More than 4/5 of the family's CW is located in countries with a cw lower
than 2%* (currently means non-top 7 country) and ASes lower than 1.5%*
(currently means non-top 8 AS)?

That implies some degree of in-family diversity since a big family would
have to spread across multiple countries/ASes.

potential problem:
"growing" ASes/countries might cross the threshold in that case you
would either have to accept the fact that someone else can take away
that badge by adding relays to your AS/CC ;) or consider the diversity
at relay signup time (less fun)


*) these are arbitrary thresholds


"No Self-Referencing Relays"
I'm not sure what exactly you mean by that but I assume it is a MyFamily
config where a relay includes his own fingerprint. Why does that hurt?
The unnecessary descriptor space/bw?

thanks



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] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

2015-09-12 Thread Tim Wilson-Brown - teor 

> On 12 Sep 2015, at 17:26, isis  wrote:
> 
> Tim Wilson-Brown - teor transcribed 23K bytes:
>> 
>>> On 10 Sep 2015, at 17:01, isis  wrote:
>>> 
 4.4.1. Bridge Reachability Self-Testing
 
  Before a Bridge uploads its descriptors to the BridgeAuthority, it
  creates a special type of testing circuit which ends at itself:
 
  Bob -> Guillaume -> Charlie -> Bob
 
  Thus, going to all this trouble to later use loose-source routing in
  order to relay Alice's traffic through Guillaume (rather than
  connecting directly to Charlie, as Alice intended) is diminished by
  the fact that Charlie can still passively enumerate Bridges by
  waiting to be asked to connect to a node which is not
  contained within the consensus.
>> 
>> Extending to an ORPort not in the consensus can also be used to enumerate
>> single onion services (prop252).  Any defences could apply to both, and if
>> they are indistinguishable, single onion services could provide cover for
>> bridges.  (Except, of course, for the defence of a single onion service being
>> a relay. That doesn’t help bridges.)
> 
> For single onion services, hiding the location/IP of the server shouldn't
> matter much, since the operator has opted into less server-side anonymity.
> (That is, it doesn't matter if an adversary can enumerate them, since they are
> services like Facebook and Blockchain.info which have chosen to be quite
> public.)
> 
> However, for "double onion services" — or whatever we're calling the thing 
> that
> is (historical) hidden services 2.0 — your point is a good one; I'm starting 
> to
> realise more and more that defences for "double onion services"¹ are possibly
> defences for bridges and vice versa.

Except that double onion services don’t need an open ORPort at all.
Due to the rendezvous mechanism, they connect like a client, rather than like a 
bridge.

>>>   2.b. If it is useful to people, then the best way I can think of so far to
>>>keep it, but refactor it to be safer, would be to create a circuit
>>>like:
>>> 
>>>Bridge → Guard → Middle → OtherMiddle → Guard → Bridge
>>> 
>>>Clearly, that circuit is just a little bit insane… but we can't do:
>>> 
>>>Bridge → Guard → Middle → Guard → Bridge
>>> 
>>>because the Middle would refuse to extend back to the previous node
>>>(all ORs follow this rule).  Similarly, it would be stupid to do:
>>> 
>>>Bridge → Guard → Middle → OtherMiddle → Bridge
>>> 
>>>because, obviously, that merely shifts the problem and accomplishes
>>>nothing.  But is there something smarter I could do?
>> 
>> I quite like this idea, and a 5-hop circuit is below the 8-hop limit.
> 
> Okay, thanks!  I'll keep this in mind as a self-testing manoeuvre we might 
> want
> to enable for both HSes and bridges.  Hopefully there's something smarter than
> "Yo! Throw some extra hops in that shit!", but if it works it works, I guess.

Well, this is “onion" routing after all… extra hops are the core of our 
anonymity
design(s).

>>> 3. Should we change how the BridgeAuthority tests Bridge ORPort 
>>> reachability?
>>>   If so, how?
>> 
>> The bridge authority could connect via a 3-hop path, but that would suffer
>> from the same issues as bridge reachability self-testing - the bridge
>> authority extending to an ORPort not in the consensus would reveal the bridge
>> to the last hop.
>> 
>> But the bridge authority could choose a set of guards (vanguards?, last-hop
>> guards?) for this purpose, reducing the chances that one is an adversary.
> 
> I started thinking about this idea, but discarded it due to thinking: "Why
> expose the bridges to other nodes at all, now that we have bridge guards?"
> 
> If anything, I suppose we could consider having the BridgeAuthority simply use
> its guards to connect to bridges… but still something feels wrong.  I feel 
> like
> this whole bridge testing system needs a giant rethinking and overhaul — 
> rather
> than simply bolting more nodes on top of a thing which doesn't really do what
> we want anyway (i.e. testing PT reachability).

Do you mean that the bridge authority should receive and use the bridge’s
guards, or the bridge authority’s guards?

If the authority already knows each bridge’s IP and ORPort, I guess that it’s
ok for it to know the bridge’s guards.

But this does seem very complicated for a design that doesn’t actually test PT
reachability (which is what we want).

Tim (teor)

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org

Re: [tor-dev] CollecTor data of the current month older than 72 hours

2015-09-12 Thread Karsten Loesing 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/15 11:58, nusenu wrote:
> Hi,
> 
> data in the /recent folder goes back 72 hours, /archive is updated
> "every few days" [1].
> 
> The latest file in the archive folder [2] is currently from
> 2015-09-07:
> 
> votes-2015-08.tar.xz  07-Sep-2015 04:11   159M
> 
> but does not contain any data from September 2015.
> 
> is there currently any data for the time period between 2015-09-01
> - 2015-09-07 9:00 on Collector or should I wait a few days?

Oops, you're right.  This is fixed now.  Sorry!

All the best,
Karsten


> thanks!
> 
> 
> [1] https://collector.torproject.org/ [2]
> https://collector.torproject.org/archive/relay-descriptors/votes/
> 
> 
> 
> ___ tor-dev mailing
> list tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJV89HHAAoJEJD5dJfVqbCr2/cH/1Q+CpgDZa5B69aKBPQ3ktOX
RVTO2zEZGFmdgxCmGwsIJfvFi3l5YbqaebjXF4ZHKQ35z4GYui3lGRb7RzXC1+lr
6uV1k4tZzBafMonI+lbq6XoydMgTLMWoV1AyZ9M+pKQk09E5choK1SsnI9VGaiOF
VEZ9jLWJLbN9fXdkShVOn/Js84Zzff1ibcT/uB5iHE2T++K/BS2NFiRLSmKspP29
1IadsJTy54t39ZYf9Kp2HLdLV3n3lL05ZhfWfqDgq+6zeZweO6Lf45o8TBgQG68h
8KRC7ifCAY8zRzL0xQLMe9F7fBAJe5+6/uTKixMmyenTYJOoTOGbG6JS3lx3aDk=
=p4QP
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

2015-09-12 Thread isis 
Tim Wilson-Brown - teor transcribed 23K bytes:
> 
> > On 10 Sep 2015, at 17:01, isis  wrote:
> > 
> >> 4.4.1. Bridge Reachability Self-Testing
> >> 
> >>   Before a Bridge uploads its descriptors to the BridgeAuthority, it
> >>   creates a special type of testing circuit which ends at itself:
> >> 
> >>   Bob -> Guillaume -> Charlie -> Bob
> >> 
> >>   Thus, going to all this trouble to later use loose-source routing in
> >>   order to relay Alice's traffic through Guillaume (rather than
> >>   connecting directly to Charlie, as Alice intended) is diminished by
> >>   the fact that Charlie can still passively enumerate Bridges by
> >>   waiting to be asked to connect to a node which is not
> >>   contained within the consensus.
> 
> Extending to an ORPort not in the consensus can also be used to enumerate
> single onion services (prop252).  Any defences could apply to both, and if
> they are indistinguishable, single onion services could provide cover for
> bridges.  (Except, of course, for the defence of a single onion service being
> a relay. That doesn’t help bridges.)

For single onion services, hiding the location/IP of the server shouldn't
matter much, since the operator has opted into less server-side anonymity.
(That is, it doesn't matter if an adversary can enumerate them, since they are
services like Facebook and Blockchain.info which have chosen to be quite
public.)

However, for "double onion services" — or whatever we're calling the thing that
is (historical) hidden services 2.0 — your point is a good one; I'm starting to
realise more and more that defences for "double onion services"¹ are possibly
defences for bridges and vice versa.

> >2.b. If it is useful to people, then the best way I can think of so far 
> > to
> > keep it, but refactor it to be safer, would be to create a circuit
> > like:
> > 
> > Bridge → Guard → Middle → OtherMiddle → Guard → Bridge
> > 
> > Clearly, that circuit is just a little bit insane… but we can't do:
> > 
> > Bridge → Guard → Middle → Guard → Bridge
> > 
> > because the Middle would refuse to extend back to the previous node
> > (all ORs follow this rule).  Similarly, it would be stupid to do:
> > 
> > Bridge → Guard → Middle → OtherMiddle → Bridge
> > 
> > because, obviously, that merely shifts the problem and accomplishes
> > nothing.  But is there something smarter I could do?
> 
> I quite like this idea, and a 5-hop circuit is below the 8-hop limit.

Okay, thanks!  I'll keep this in mind as a self-testing manoeuvre we might want
to enable for both HSes and bridges.  Hopefully there's something smarter than
"Yo! Throw some extra hops in that shit!", but if it works it works, I guess.

> > 3. Should we change how the BridgeAuthority tests Bridge ORPort 
> > reachability?
> >If so, how?
> 
> The bridge authority could connect via a 3-hop path, but that would suffer
> from the same issues as bridge reachability self-testing - the bridge
> authority extending to an ORPort not in the consensus would reveal the bridge
> to the last hop.
>
> But the bridge authority could choose a set of guards (vanguards?, last-hop
> guards?) for this purpose, reducing the chances that one is an adversary.

I started thinking about this idea, but discarded it due to thinking: "Why
expose the bridges to other nodes at all, now that we have bridge guards?"

If anything, I suppose we could consider having the BridgeAuthority simply use
its guards to connect to bridges… but still something feels wrong.  I feel like
this whole bridge testing system needs a giant rethinking and overhaul — rather
than simply bolting more nodes on top of a thing which doesn't really do what
we want anyway (i.e. testing PT reachability).


¹ Sorry, but — after having to type that twice — that name sucks.

Best Regards,
-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt


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] CollecTor data of the current month older than 72 hours

2015-09-12 Thread nusenu 

> This is fixed now.
thanks!



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