-
Notifications
You must be signed in to change notification settings - Fork 84
/
257-hiding-authorities.txt
213 lines (148 loc) · 8.04 KB
/
257-hiding-authorities.txt
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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
Filename: 257-hiding-authorities.txt
Title: Refactoring authorities and making them more isolated from the net
Authors: Nick Mathewson, Andrea Shepard
Created: 2015-10-27
Status: Meta
0. Meta status
This proposal is 'accepted' as an outline for future proposals, though
it doesn't actually specify itself in enough detail to be implemented as
it stands.
1. Introduction
Directory authorities are critical to the Tor network, and represent
a DoS target to anybody trying to disable the network. This document
describes a strategy for making directory authorities in general less
vulnerable to DoS by separating the different parts of their
functionality.
2. Design
2.1. The status quo
This proposal is about splitting up the roles of directory
authorities. But, what are these roles? Currently, directory
authorities perform the following functions.
Some of these functions require large amounts of bandwidth; I've noted
that with a (BW). Some of these functions require a publicly known
address; I've marked those with a (PUB). Some of these functions
inevitably leak the location from which they are performed. I've marked
those with a (LOC).
Not everything in this list is something that needs to be done by an
authority permanently! This list is, again, just what authorities do now.
* Authorities receive uploaded server descriptors and extrainfo
descriptors from regular Tor servers and from each other. (BW, PUB?)
* Authorities periodically probe the routers they know about in
order to determine whether they are running or not. By
remembering the past behavior of nodes, they also build a view of
each node's fractional uptime and mean time between
failures. (LOC, unless we're clever)
* Authorities perform the consensus protocol by:
* Generating 'vote' documents describing their view of the
network, along with a set of microdescriptors for later
client use.
* Uploading these votes to one another.
* Computing a 'consensus' of these votes.
* Authorities serve as a location for distributing consensus
documents, descriptors, extrainfo documents, and
microdescriptors...
* To directory mirrors. (BW?, PUB?, LOC?)
* To clients that do not yet know a directory mirror. (BW!!, PUB)
These functions are tied to directory authorities, but done
out-of-process:
* Bandwidth measurement (BW)
* Sybil detection
* 'Guardiness' measurement, possibly.
2.2. Design goals
Principally, we attempt to isolate the security-critical,
high-resource, and availability-critical pieces of our directory
infrastructure from one another.
We would like to make the security-critical pieces of our
infrastructure easy to relocate, and the communications between them
easy to secure.
We require that the Tor network remain able to bootstrap itself in
the event of catastrophic failure. So, while we can _use_ a running
Tor network to communicate, we should not _require_ that a running
Tor network exist in order to perform the voting process.
2.3. Division of responsibility
We propose dividing directory authority operations into these modules:
---------- ---------- -------------- ----------------
| Upload |======>| Voting |===>| Publishing |===>| Distribution |
---------- ---------- -------------- ----------------
I ^
I ----------- I
====>| Metrics |===
-----------
A number of 'upload' servers are responsible for receiving
router descriptors. These are publicly known, and responsible for
collecting descriptors.
Information from these servers is used by 'metrics' modules
(which check Tor servers for reliability and measure their history),
and fed into the voting process.
The voting process involves only communication (indirectly) from
authorities to authorities, to produce a consensus and a set of
microdescriptors.
When voting is complete, consensuses, descriptors, and microdescriptors
must be made available to the rest of the world. This is done by
the 'publishing' module. The consensuses, descriptors, and mds are then
taken up by the directory caches, and distributed.
The rest of this proposal will describe means of communication between
these modules.
3. The modules in more detail
This section will outline possibilities for communication between the
various parts of the system to isolate them. There will be plenty of
"may"s and "could"s and "might"s here: these are possibilities, in
need of further consideration.
3.1. Sending descriptors to the Upload module
We retain the current mechanism: a set of well-known IP
addresses with well-known OR keys to which each relay should upload a
copy of its descriptors.
The worst that a hostile upload server can do is to drop descriptors.
(It could also generate large numbers of spurious descriptors in
order to increase the load on the metrics system. But an attacker
could do that without running an upload server)
With respect to dropping, upload servers can use an anytrust model:
so long as a single server receives and honestly reports descriptors
to the rest of the system, those descriptors will arrive correctly.
To avoid DoS attacks, we can require that any relay not previously known
to an upload module perform some kind of a proof of work as it first
registers itself. (Details TBD)
If we're using TLS here, we should also consider a check-then-start TLS
design as described in A.1 below.
The location of Upload servers can change over time; they can be
published in the consensus.
(Note also that as an alternative, we could distribute this functionality
across the whole network.)
3.2. Transferring descriptors to the metrics server and the voters
The simplest option here would be for the authorities and metrics
servers to mirror them using Tor. rsync-over-ssh-over-Tor is a
possibility, if we don't feel like building more machinery.
(We could use hidden services here, but it is probably okay for
upload servers and to be known by the the voters and metrics.)
A fallback to a non-Tor connection could be done manually, or could
require explicit buy-in from the voter/metrics operator.
3.3. Transferring information from metrics server to voters
The same approaches as 3.2 should work fine.
3.4. Communication between voters
Voters can, we hope, communicate to each other over authenticated
hidden services. But we'll need a fallback mechanism here.
Another option is to have public ledgers available for voters to talk
to anonymously. This is probably a better idea. We could re-use the
upload servers for this purpose, perhaps.
Giving voters each others' addresses seems like a bad idea.
3.5. Communication from voters to directory nodes
We should design a flood-distribution mechanism for microdescriptors,
listed descriptors, and consensuses so that authorities can each
upload to a few targets anonymously, and have them propagate through
the rest of the network.
4. Migration
To support old clients and old servers, the current authority IP
addresses should remain as Upload and Distribution points. The
current authority identity keys keys should remain as the keys for
voters.
A.1. Check-then-start TLS
Current TLS protocols are quite susceptible to denial-of-service
attacks, with large asymmetries in resource consumption. (Client
sends junk, forcing server to perform private-key operation on junk.)
We could hope for a good TLS replacement to someday emerge, or for
TLS to improve its properties. But as a replacement, I suggest that
we wrap TLS in a preliminary challenge-response protocol to establish
that the use is authorized before we allow the TLS handshake to
begin.
(We shouldn't do this for all the TLS in Tor: only for the cases
where we want to restrict the users of a given TLS server.)