Re: [tor-bugs] #7520 [BridgeDB]: Design and implement a social distributor for BridgeDB

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7520: Design and implement a social distributor for BridgeDB
-------------------------+--------------------------------------------------
 Reporter:  aagbsn       |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  BridgeDB     |        Version:     
 Keywords:  SponsorZ     |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------
Changes (by sysrqb):

 * cc: Matthew.Finkel@â (added)


Comment:

 Thanks for the feedback asn!

 Replying to [comment:12 asn]:
 > Replying to [comment:10 sysrqb]:
 > > (I'll post more later, but for now...)
 > >
 > > After reading rBridge, Proximax, Kaleidoscope, Tor's blocking
 resistance paper:
 > >
 > > some thoughts on a future system:
 >
 > I also agree that cherry-picking features we like from all these
 schemes, might be a good way to design a decent future BridgeDB. Adding
 some notes on my own:
 >
 > >
 > > - We will want multiple pools (possibly three, to start off: Automated
 distribution, manual distribution, reserve)
 > > - Use of a credential system that awards users via allocation of
 credits seems like a good idea
 > > - Awarding credits based on a bridges user-hours value seems like a
 good idea
 >
 > You mean based on bridge uptime (like the rBridge paper)? I also like
 this idea.

 Yup. From what I can tell the idea actually originated in the proximax
 paper and then was improved in rBridge.

 >
 > > - We should try to add the "intrinsic risk" of a bridge into the
 reputation calculations
 > > - Without the use of NIPK and OT, the BridgeDB operators MUST be
 trusted
 >
 > Yeah, the threat model of BridgeDB will have to remain the same on this
 matter.
 > I'd also like BridgeDB to have all those fancy rBridge
 cryptowan^Wfeatures (ZKP/OT/etc.), but I really doubt we can implement
 them efficiently/securely/in the next 5 years. I don't know a single
 widely used application with oblivious transfer capabilities.
 >

 Yeah, sad reality. I made this point specifically regarding aagbsn's
 BridgeHerder idea and the idea that third parties can run BridgeDB social
 distributors. BridgeHerder really is a good idea, but I hadn't really
 thought about it until I read the rBridge paper. After reading it I
 realized how dangerous a compromised BridgeDB instance can be to a user's
 anonymity.

 > BTW, as far as the BridgeDB threat model goes, note that all these
 reputation-based systems probably require BridgeDB to keep accounting logs
 for users ("user X got bridges at TIMESTAMP", "user X invited user Y",
 etc.). This is not the case with the current BridgeDB.
 >

 This is true and a valid point (which is where the zero knowledge
 implementation shines) and I think we need to discuss/debate/design the
 best way to handle this information such that the users are put in the
 least amount of danger.

 > > - Reputation should not only be based on a social tree
 > > - We can use the bridge's geoip stats to *help* determine when the
 bridge has been blocked within a zone
 > > - Bridges can be selected based on the user's identity rather than
 location. (Really, how bad is random selection?)
 > > - Do we want to maintain an ID system (ex. Persona)?
 >
 > By ID system, you mean some kind of identifier per user other than an IP
 address? I guess we will need such a system, if we want to build the whole
 invitation/credential-based idea.
 >

 Right, we will need some way to create/maintain accounts. I know, at the
 least, mikeperry and isis were looking at persona (independently). We must
 be careful about which implementation we use, as well.

 > Will the bridge selection happen based on the ID of the user, or the IP
 address of the user? For example, Persona is based on a single email
 address; will a user who creates multiple Persona IDs be able to get more
 than a single bunch of bridges?
 >

 Good question. rBridge selects all bridge randomly, I haven't decided if I
 like this yet. If we don't want to do that, we could base selection on the
 MAC of the userid + nonce (or something similar). I think how we choose to
 select bridges will really depend on how bridges are stored (i.e. will we
 still use rings?).

 > > - We need reachability testing...yesterday
 > > - When we determine (within a reasonably high probability) that a user
 is a censor and/or in cohorts with one, only supply blocked bridges
 > > - GEO IP tracking by a bridge needs to distinguish between direct
 connections and connections via PT
 > > - Can we use standalone PT nodes within a censored zone to obscure a
 connection between a PT client and bridge?
 > > - How do we prevent sybils when we have registered users?
 > > - If we don't track the social graph, can we somehow factor it into
 our calculations? (assuming a registered users may distribute her bridges
 to friends)
 > > - Is the use of FQDN as bad an idea as I think it is?
 >
 > FQDN? What do you mean?

 Sorry, Fully-Qualified domain names. Proximax relies on the clients using
 domain names instead of IP addresses. Multiple bridge's are mapped to the
 same domain name, and are used in round-robin. When an IP address is
 blocked, then proximax assigns a new bridge's IP address to the domain
 name, etc. If the domain name is blocked then proximax simply deploys a
 new domain.

 I have some reservations about this idea, but I haven't decided if they're
 well-founded yet.

 >
 > > - Low plausible deniability that you don't have credentials if you use
 Tor
 > >
 >
 > What do you mean on this one?

 Currently if you're using Tor in a censored zone you may have received
 bridge addresses from BridgeDB, or a friend, or help@tpo, etc. If we
 switch to a social distributor model based on rBridge, then if a person is
 using Tor, they most likely either received a bridge from BridgeDB or
 help@. If they received it from BridgeDB then they must have credentials,
 and if those credentials fall into the wrong hands it would be detrimental
 (blocked bridges and, depending on the regime, dangerous for the user).

 >
 > Thanks for looking into this! I like where it's going.

 This was more brain-dump than something constructive, I appreciate the
 feedback though. I'll work on writing Something-Constructive soon.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7520#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs