| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889 |
- 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'
|
