1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
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'
|
