[tor-bugs] #19728 [Core Tor/Tor]: Pick, and deploy, a new bridge authority

[Tor Bug Tracker & Wiki]

#19728: Pick, and deploy, a new bridge authority
--------------------------+------------------------------------
 Reporter:  arma          |          Owner:
     Type:  task          |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Description changed by arma:

Old description:

> We are losing Tonga at the end of August (#19690). That means we should
> spin up a new bridge authority.
>
> What are the criteria we should be considering, for the operator,
> location, etc of this bridge authority? To answer that, I think we should
> start by brainstorming all of the risks that we should consider.
>
> So: what are we trusting the bridge authority for? Related, what does the
> bridge authority see? And what does an adversary watching the bridge
> authority see?
>
> First, it sees the unscrubbed bridge data, i.e. the IP addresses, usage
> stats, fingerprints, etc of bridges. I think this is the same as what
> bridgedb sees, but more detailed than what onionoo serves. We rely on the
> bridge authority to have high security so bad people can't break in and
> steal the bridge addresses (that's number 7 on
> https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-
> bridges).
>
> Second, the bridge authority does bridge reachability tests. So somebody
> who watches its network connection gets to learn bridge addresses too.
> (Bridges use Tor, and encrypted begindir connections, to *publish* their
> descriptors to the bridge authority, so you can't learn about them that
> way.) This part is probably a design flaw, in that it's a shame we have
> centralized the reachability testing; but we don't have a better design
> for that currently, so it remains an issue here.
>
> Third, it *used* to be the case, in the original design, that the bridge
> authority needs to have really high reliability and bandwidth. That
> requirement was because users were expected to go back to the bridge
> authority quite frequently, to see if their bridges have changed
> location. The original idea was that users would get n bridges, and over
> time k of them would move locations or something, and so long as at least
> 1 of the n remained working, the Tor client could automatically discover
> the new bridge locations by fetching updated bridge descriptors from
> Tonga. But we basically stopped building the bridge design before we got
> that part working, so it isn't really an issue here.
>
> What other constraints/risks/goals did I miss?

New description:

 We are losing Tonga at the end of August (#19690). That means we should
 spin up a new bridge authority.

 What are the criteria we should be considering, for the operator,
 location, etc of this bridge authority? To answer that, I think we should
 start by brainstorming all of the risks that we should consider.

 So: what are we trusting the bridge authority for? Related, what does the
 bridge authority see? And what does an adversary watching the bridge
 authority see?

 First, it sees the unscrubbed bridge data, i.e. the IP addresses, usage
 stats, fingerprints, etc of bridges. I think this is the same as what
 bridgedb sees, but more detailed than what onionoo serves. We rely on the
 bridge authority to have high security so bad people can't break in and
 steal the bridge addresses (that's number 7 on
 https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-
 bridges).

 Second, the bridge authority does bridge reachability tests. So somebody
 who watches its network connection gets to learn bridge addresses too.
 (Bridges use Tor, and encrypted begindir connections, to *publish* their
 descriptors to the bridge authority, so you can't learn about them that
 way.) This part is probably a design flaw, in that it's a shame we have
 centralized the reachability testing; but we don't have a better design
 for that currently, so it remains an issue here. (This is number eight on
 the blog post above.)

 Third, it *used* to be the case, in the original design, that the bridge
 authority needs to have really high reliability and bandwidth. That
 requirement was because users were expected to go back to the bridge
 authority quite frequently, to see if their bridges have changed location.
 The original idea was that users would get n bridges, and over time k of
 them would move locations or something, and so long as at least 1 of the n
 remained working, the Tor client could automatically discover the new
 bridge locations by fetching updated bridge descriptors from Tonga. But we
 basically stopped building the bridge design before we got that part
 working, so it isn't really an issue here.

 What other constraints/risks/goals did I miss?

--

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