authority-policy.txt 3.8 KB

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