mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +01:00
90 lines
3.8 KiB
Plaintext
90 lines
3.8 KiB
Plaintext
|
|
0. Overview.
|
|
|
|
This document contains various informal policies for how to operate
|
|
a directory authority, how to choose new ones, etc.
|
|
|
|
1. How to pick a new directory authority.
|
|
|
|
Here's our current guidelines for how to pick new directory
|
|
authorities.
|
|
|
|
(These won't ever be formal criteria -- we need to keep this flexible
|
|
so we can adapt to new situations.)
|
|
|
|
o Stability:
|
|
- Must be a low-downtime Tor server (computer as well as network).
|
|
- Must have a static IP.
|
|
- The operator must have been running a stable Tor server for at least
|
|
3 months.
|
|
- Must intend for this server to stick around for the next 12 months
|
|
or more.
|
|
- Must not hibernate.
|
|
- Should not be an exit node (as this increases the risk both of
|
|
downtime and of key compromise).
|
|
|
|
o Performance:
|
|
- Must have sufficient bandwidth: at least 300 kB/s symmetric,
|
|
though in practice the inbound traffic can be considerably less.
|
|
|
|
o Availability:
|
|
- Must be available to upgrade within a few days in most cases.
|
|
(While we're still developing Tor, we periodically find bugs that
|
|
impact the whole network and require authority upgrades.)
|
|
- Should have a well-known way to contact the administrator
|
|
via PGP-encrypted message.
|
|
|
|
o Integrity:
|
|
- Must promise not to censor or attack the network and users.
|
|
- Should be run by somebody that Tor (i.e. Roger) knows.
|
|
- Should be widely regarded as fair/trustworthy, or at least
|
|
known, by many people.
|
|
- If somebody asks you to backdoor or change your server, legally or
|
|
otherwise, you will fight it to the extent of your abilities. If
|
|
you fail to fight it, you must shut down the Tor server and notify
|
|
us that you have.
|
|
|
|
o Diversity
|
|
- We should avoid situations that make it likelier for multiple
|
|
authority failures to happen at the same time. Therefore...
|
|
- It's good when authorities are not all in the same country.
|
|
- It's good when authorities are not all in the same jurisdictions.
|
|
- It's good when authorities are not all running the same OS.
|
|
- It's good when authorities are not all using the same ISP.
|
|
- It's good when authorities are not all running the same
|
|
version of Tor.
|
|
- No two authorities should have the same operator.
|
|
- Maximal diversity, however, is not always practical. Sometimes,
|
|
for example, there is only one version of Tor that provides a
|
|
given consensus generation algorithm.
|
|
- A small group of authorities with the same country/jurisdiction/OS is
|
|
not a problem, until that group's size approaches quorum (half the
|
|
authorities).
|
|
|
|
2. How to choose the recommended versions
|
|
|
|
The policy, in a nutshell, is to not remove versions without a good
|
|
reason. So this means we should recommend all versions except:
|
|
|
|
- Versions that no longer conform to the spec. That is, if they wouldn't
|
|
actually interact correctly with the current Tor network.
|
|
- Versions that have known security problems.
|
|
- Versions that have frequent crash or assert problems.
|
|
- Versions that harm the performance or stability of the current Tor
|
|
network or the anonymity of other users. For example, a version
|
|
that load balances wrong, or a version that hammers the authorities
|
|
too much.
|
|
|
|
|
|
> some use the slight variant of requiring a *good* reason.
|
|
> excellent reasons include "there's a security flaw"
|
|
> good reasons include "that crashes every time you start it. you would think
|
|
+tor is dumb if you tried to use that version and think of it as tor."
|
|
> good reasons include "those old clients do their load balancing wrong, and
|
|
+they're screwing up the whole network"
|
|
> reasons include "the old one is really slow, clients should prefer the new
|
|
+one"
|
|
> i try to draw the line at 'good reasons and above'
|
|
|
|
|