[anti-censorship-team] Plans for BridgeDB's future

[Roger Dingledine]

On Tue, May 12, 2020 at 03:17:07PM -0700, Philipp Winter wrote:
> In a nutshell, Salmon hands out bridges to users while maintaining
> per-user reputation scores.  Alice's reputation goes up if her bridge
> remains unblocked after she got it, and it goes down if the bridge is
> blocked after Alice got it.  Users can invite each other, which results
> in an invitation graph.  Eventually, we will hopefully have a Salmon
> distributor which will live alongside our Moat, HTTPS, and Email
> distributors.

I am still optimistic about Salmon. Here are some thoughts I wrote while
re-reading it, highlighting unanswered pieces and potential thorny issues
once you look deeper into the design.

(1) How critical is the initial anti-sybil step? That is, how much impact
does its effectiveness have on whether the rest of the system works? My
mental model here is like 'sensitivity analysis', where the question is
whether a small change here produces a big change later in the system.

I guess the answer is: when not under attack, it doesn't much matter
how effective the anti-sybil step is. But under a good attack, if the
attacker can become "most" of the new users joining the system, and
especially if they can sustain that, then there's a bad spiral where
new real users can't ever get good service so they leave, making it
easier for the attacker to sustain "most".

On the plus side though, the attacker really needs to sustain the attack
-- if they miss out on getting a user onto any bridge, then the people
who got that bridge will be winners.

(2) From an engineering angle, is "check the Facebook account" the
right primitive to use here? How does the user prove possession of the
Facebook account to us? Are there libraries that do this, and if not,
what do they know that we don't know. :)

(3) How dangerous is the social graph of which users recommended which
users? The authors argue that the censors essentially already have this
data from real social networks, so there's no additional risk here. Do
we buy that?

Can this "social graph" component of the design be treated as a modular
thing and made less dangerous, like with cool crypto techniques,
without losing functionality? Is that essentially a hybrid design with
other papers?

(One example I was pondering would be to add randomized "noise" links
for some fraction of new users, so it looks like they were recommended,
and now when you see a recommendation link, you know it's 50% likely
to be artificial. But that idea seems to be at odds with the strategy
of putting low-trust users onto high-trust servers alongside their
high-trust recommenders.)

(4) I still worry about false positives, where a bridge gets blocked
for other reasons than "one of the users we assigned to it was bad". At
the extreme end, imagine Iran rolls out protocol whitelisting for a day:
obfs4 stops working, and we blame all the users of all the bridges.

In the analysis, imagine another variable, which is the chance that
the adversary discovered the bridge through some other (external)
mechanism. The paper assumes this chance is 0%, but if it goes to 5%,
how much falls apart? This question makes me especially nervous because
"what if the rate isn't independent for each bridge?"

Similarly, another variable is the false positive rate where we
mistakenly think a server got blocked but actually it just went down. In
theory we can make this rate 0% by doing external reachability checking
too, but if those results are noisy, what does it do to the design? All
users eventually get kicked out no matter what? Do we need a slow
'forgiveness' multiplier to make things work in the long term? Or does
regrowing trust undermine the rest of the design too much, because it
is more useful to the adversary than it is to the users?

(5) How to adapt this design to multiple countries? Right now all the
analysis is "if the bridge gets blocked", but if it gets blocked in
China but not Venezuela, is it clear what we do? It seems like we need
to blame every user (no matter what country they claim to be in), but
maybe we only need to move the blocked ones.

Do we want "per-country trust scores" for each user? Or is "four strikes,
anywhere in the world, even if two of them are China and two of them are
Venezuela, and you're out" good enough? (Back in 2016, the authors told
me they had in mind to track per-country trust scores, and ban the user
if they got four strikes in any single country.)

In order to move only the blocked users, do we need to know which country
each user is in? How much does it matter that sometimes blocking isn't
uniform within a country?

(6) What is the right mechanism for the out-of-band (meta communication)
channel? The paper suggests email, which has the advantage that if the
account identifier is an email address, we can use it to push info to
users, like "we think your bridge went away, here's a new one."

But the moat experience is compelling too, where Tor Browser
uses meek-azure to get updates as needed, and then so long as that
mechanism still works, the entire process of replacing the bridge can be
automated.

Tying the identity into the Tor Browser install introduces some subtle
usability questions, like how to export your identity if you want to
switch Tor Browsers, and whether many Tor Browsers can "be" the same
person (and what that does to load balancing on bridges).

In fact, the paper expects this automation, with ideas like "when the
client tells the directory that the server is offline" -- in 2016 the
authors told me they wanted to automate the email interaction, including
logging in to the email server, auto parsing the mails, etc. But now
moat might be easier to build as the first iteration.

(7) Do we need to batch "reassignment" events? That is, if ten users
have a bridge, and the bridge gets blocked, now we have ten users at the
same trust level who need a new bridge. If we assign all ten pending
users to the same new bridge, then we're not actually spreading users
out after blocking events. Other reputation designs have epochs where
all the reconfiguration changes happen between epochs, but here the
security comes from minimizing reconfigurations. How do we balance the
need to randomize replacement allocations vs getting users up and running
quickly with a new working bridge?

(8) How much better can the adversary strategies get, for blocking as
many users as possible?

For a first example, here's a better strategy than any of the ones in
the paper: "the attacker defects early when k or fewer attackers are
in the group, and it waits a while to defect when it has more than k
attackers in the group."

An even better strategy might take advantage of whatever reassignment
batching algorithm we pick in #7 above, to decide which *combination*
of bridges to fail at once, in order to get the desired set of users in
the reassignment phase.

--Roger