[tor-bugs] #26778 [Core Tor/Tor]: Enable supporting multiple bridge authorities

[Tor Bug Tracker & Wiki]

#26778: Enable supporting multiple bridge authorities
-------------------------------------------------+-------------------------
 Reporter:  chelseakomlo                         |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-bridges needs-testing? needs-    |  Actual Points:
  proposal?                                      |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by chelseakomlo):

 Replying to [comment:1 arma]:
 > My first thought here is that I believe it should work right now for Tor
 to have two bridge auths, and bridges will simply publish their bridge
 descriptor to both of them. (And by "two" I mean "n".)

 Ok, that is good to hear. The main purpose of this is to ensure that tor
 can have more than one bridge authority.

 > Then the bridge auths become redundant, i.e. one of them can catch fire
 but the pipeline still gets the bridges through.
 >
 > One downside of that style of redundancy is increased surface area: that
 is, there is one more place in the world that has the list of bridges and
 that is making connections to all the bridges.
 >
 > But I think it will take much more design to produce a "distributed"
 bridge authority that actually has reduced surface area in practice. (For
 example, if each bridge alternates each day which authority it sends its
 descriptor to, are we really gaining that much?)

 What is the risk of only sending it to the first authority that accepts
 the descriptor (from a authority chosen at random)? As BridgeDB is the
 point which takes the union of all descriptors, I would think relays
 uploading descriptors could load balance across available authorities.

 But in practice it might not matter whether the bridge sends the
 descriptor to n authorities or 1, if n=2 or even if n=5.

 > Also, in the original bridge authority design, which still sort of works
 in the code right now, clients would reach out to the bridge authority
 directly (or via a Tor circuit using an existing working bridge) to fetch
 new descriptors for bridges that moved addresses. So if we want to keep
 that design possible for the future, we need bridges to
 *deterministically* assign themselves to bridge authorities, such that
 clients can predict the assignment too. See #2473. Maybe we want to close
 off that design because it's more trouble than it's worth, but also maybe
 not.

 As I understand, there is a proposal where BridgeDB becomes distributed
 https://gitweb.torproject.org/torspec.git/tree/proposals/226-bridgedb-
 database-improvements.txt to mitigate against single points of failure
 cases.

 What is the benefit of clients reaching out to authorities directly for
 bridge assignments, as opposed to BridgeDB being the single point where
 clients fetch bridges?

 > tl;dr I think what you want is already in the code base, so long as
 you're ok with a slight tweak to what you want. :)

 Mainly I wanted to ensure that today more than one bridge authority can
 exist, so it is good that this can already happen.

 If you can point me to where the "bridge uploads its descriptor to all
 bridge authorities" happens in the code, that would be helpful, I wanted
 to dig into this a bit more.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26778#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online