doc/contrib/authority-policy.txt

   1
   2 0. Overview.
   3
   4    This document contains various informal policies for how to operate
   5    a directory authority, how to choose new ones, etc.
   6
   7 1. How to pick a new directory authority.
   8
   9    Here's our current guidelines for how to pick new directory
  10    authorities.
  11
  12    (These won't ever be formal criteria -- we need to keep this flexible
  13    so we can adapt to new situations.)
  14
  15    o Stability:
  16      - Must be a low-downtime Tor server (computer as well as network).
  17      - Must have a static IP.
  18      - The operator must have been running a stable Tor server for at least
  19        3 months.
  20      - Must intend for this server to stick around for the next 12 months
  21        or more.
  22      - Must not hibernate.
  23      - Should not be an exit node (as this increases the risk both of
  24        downtime and of key compromise).
  25
  26    o Performance:
  27      - Must have sufficient bandwidth: at least 300 kB/s symmetric,
  28        though in practice the inbound traffic can be considerably less.
  29
  30    o Availability:
  31      - Must be available to upgrade within a few days in most cases.
  32        (While we're still developing Tor, we periodically find bugs that
  33        impact the whole network and require dirserver upgrades.)
  34      - Should be have a well-known way to contact the administrator
  35        via PGP-encrypted message.
  36
  37    o Integrity:
  38      - Must promise not to censor or attack the network and users.
  39      - Should be run by somebody that Tor (i.e. Roger) knows.
  40      - Should be widely regarded as fair/trustworthy, or at least
  41        known, by many people.
  42      - If somebody asks you to backdoor or change your server, legally or
  43        otherwise, you will fight it to the extent of your abilities. If
  44        you fail to fight it, you must shut down the Tor server and notify
  45        us that you have.
  46
  47    o Diversity
  48      - We should avoid situations that make it likelier for multiple
  49        dirserver failures to happen at the same time.  Therefore...
  50        - It's good when dirservers are not all in the same country.
  51        - It's good when dirservers are not all in the same jurisdictions.
  52        - It's good when dirservers are not all running the same OS.
  53        - It's good when dirservers are not all using the same ISP.
  54        - It's good when dirservers are not all running the same
  55          version of Tor.
  56        - No two dirservers should have the same operator.
  57      - Maximal diversity, however, is not always practical.  Sometimes,
  58        for example, there is only one version of Tor that provides a
  59        given consensus generation algorithm.
  60      - A small group of authorities with the same country/jurisdiction/OS is
  61        not a problem, until that group's size approaches quorum (half the
  62        authorities).
  63
  64 2. How to choose the recommended versions
  65
  66   The policy, in a nutshell, is to not remove versions without a good
  67   reason. So this means we should recommend all versions except:
  68
  69   - Versions that no longer conform to the spec. That is, if they wouldn't
  70     actually interact correctly with the current Tor network.
  71   - Versions that have known security problems.
  72   - Versions that have frequent crash or assert problems.
  73   - Versions that harm the performance or stability of the current Tor
  74     network or the anonymity of other users. For example, a version
  75     that load balances wrong, or a version that hammers the authorities
  76     too much.
  77
  78
  79 > some use the slight variant of requiring a *good* reason.
  80 > excellent reasons include "there's a security flaw"
  81 > good reasons include "that crashes every time you start it. you would think
  82 +tor is dumb if you tried to use that version and think of it as tor."
  83 > good reasons include "those old clients do their load balancing wrong, and
  84 +they're screwing up the whole network"
  85 > reasons include "the old one is really slow, clients should prefer the new
  86 +one"
  87 > i try to draw the line at 'good reasons and above'
  88
  89