Pick, and deploy, a new bridge authority
We are losing Tonga at the end of August (#19690 (moved)). 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.
Fourth (added based on Sebastian's comment below), we are relying on the bridge authority to have a consistent IP address for a very long time, since bridges upload their descriptors using this address. That is, I think it is the case that changing its IP address is effectively the same as picking a new bridge authority?
What other constraints/risks/goals did I miss?
Activity
changed milestone to %Tor: 0.2.4.x-final
Trac:
Description: We are losing Tonga at the end of August (#19690 (moved)). 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?
to
We are losing Tonga at the end of August (#19690 (moved)). 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?
-
Because of "Second", I am unexcited about putting the bridge authority under the nose of any intelligence agency. Wherever we put it, it's a gift to whoever's network it's on. So in that sense the network location is at least as important as the security of the system itself. If somebody can point us at a network location where no adversaries can watch, let us know. :) Otherwise, it's about choosing which adversary to stick it next to, and that is a crummy choice to have to make.
Because of "First", I think putting it nearby (in terms of trust) to bridgedb or the metrics archiver makes a lot of sense.
Sebastian makes a good point above that "location stability" is a key requirement for the bridge authority.
-
Trac:
Description: We are losing Tonga at the end of August (#19690 (moved)). 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?
to
We are losing Tonga at the end of August (#19690 (moved)). 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.
Fourth (added based on Sebastian's comment below), we are relying on the bridge authority to have a consistent IP address for a very long time, since bridges upload their descriptors using this address. That is, I think it is the case that changing its IP address is effectively the same as picking a new bridge authority?
What other constraints/risks/goals did I miss?
-
Replying to Sebastian:
It needs as stable an IP address as we can get it, because we have just one (and having more than one is a nice theory for later at this point).
Good one! I added that as "Fourth" above.
I suggest adding something which will allow us some space for further moves: if the hardcoded IP address of the bridge authority is unreachable, fallback to the A and/or AAAA record (DNSSEC signed) for bridgeauth.torproject.org. It's not a fantastic fix but will at least make further migrations slightly easier. I guess we can assume that there will be bigger problems than the bridge authority to worry about in case something happens to torproject.org domain name.
-
Replying to Sebastian:
Oh. You need ipv6.
I don't think you need ipv6. Maybe you need it for the ipv6 reachability tests, but I bet everything would work just fine if the bridge authority just declares that it doesn't know how to do ipv6 reachability testing.
But you don't, for example, need to be reachable on an ipv6 address, since everybody interacts with the bridge authority via Tor.
While IPv6 might not be strictly required it should really be there for the bridge authority in my opinion. While it's not as widely deployed consumer wise as I'd like, IPv6 is possible to get in most data centers - and I'd really hate that some node was picked where we'll then have to switch again in a few years (hopefully) when we then really need IPv6.
Trac:
Username: lakridserne-
FWIW I am more than happy to host this ( https://mobile.twitter.com/BrassHornComms/status/755382167706955776 ) BrassHorn announces IPv6 and IPv4 via its own ASN (AS28715)
Recently some of my relays were added to the fallback dir list ( https://mobile.twitter.com/BrassHornComms/status/728630564706603008 ) which I hope goes someway to showing the reliability of my network.
Trac:
Username: BrassHornComms Replying to BrassHornComms:
FWIW I am more than happy to host this ( https://mobile.twitter.com/BrassHornComms/status/755382167706955776 ) BrassHorn announces IPv6 and IPv4 via its own ASN (AS28715)
Recently some of my relays were added to the fallback dir list ( https://mobile.twitter.com/BrassHornComms/status/728630564706603008 ) which I hope goes someway to showing the reliability of my network.
I just wanted to clarify here - the list you linked to in that tweet was an opt-in whitelist. Anyone could opt-in, and we specifically contacted operators of stable relays with at least a few megabits of bandwidth.
Then we ran a script that ranked the opt-in list of relays by bandwidth, checked them for reliability, and selected the top 100. That produced the 0.2.8.5-rc list of fallback directories: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc
The Brass Horn relays aren't on the fallback list for 0.2.8.5-rc, because the bandwidth cutoff was ~6 Mbps, and the Brass Horn relays that were opted in were below that.
For the record, the bridge authority details that we hard-code in the Tor source code are:
"Tonga orport=443 bridge " "82.94.251.203:80 4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D",The bridge authority needs a stable IPv4, ports, and key. (The key isn't mentioned in the ticket description - it's implicit, but it does mean that we should pick one operator with key access, and stick with them.)
There is no reason for us to hard-code an IPv6 address, as nothing needs to contact the bridge authority on IPv6.
-
Replying to teor:
The Brass Horn relays aren't on the fallback list for 0.2.8.5-rc, because the bandwidth cutoff was ~6 Mbps, and the Brass Horn relays that were opted in were below that.
Ah, well once I've finished getting IXP peering sorted bandwidth will become a lot cheaper and will allow for a significant increase in relay speeds!
Trac:
Username: BrassHornComms
