diff options
Diffstat (limited to 'attic/authority-policy.txt')
| -rw-r--r-- | attic/authority-policy.txt | 89 |
1 files changed, 89 insertions, 0 deletions
diff --git a/attic/authority-policy.txt b/attic/authority-policy.txt new file mode 100644 index 0000000..7072082 --- /dev/null +++ b/attic/authority-policy.txt @@ -0,0 +1,89 @@ + +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 10mbit/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' + + |