-
Notifications
You must be signed in to change notification settings - Fork 30
/
TODO
389 lines (361 loc) · 17.7 KB
/
TODO
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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
Notes on 16 July 2012
Here are some things that Mixminion (the software) would need to have before
I would consider it safe to use:
* Increase the DH key size on TLS from 768 bytes to something reasonable;
enable ECC in TLS.
* Implement a conservative distributed-trust directory system, possibly
based on Tor's.
* Replace SHA1 with SHA256 or SHA512.
* Do all crypto in C, using mlock and friends to avoid attacks.
Here are some things that I think Mixminion (the software) ought to have for
security:
* Switch to the "Sphinx" packet format.
http://crysp.uwaterloo.ca/software/Sphinx-0.8.tar.gz
* Reconsider dummies and link padding based on research in the last 10
years.
And here are some things I think it needs to be usable:
* Implement a pinger that feeds into the authority votes. (There's one
started. It should be decoupled from the rest of the code, and not run
in the same process as a server.) See echolot and leuchtfeur.
* Investigate why, as of 2012, mixminion mails don't arrive. I suspect
that it's that "lack of a pinger" thing, possibly combined with one or 2
unknown bugs.
* Drop the E2E-spec envelope format; use something less nutty and
restrictive.
* Support IPv6
* Needs a working nymserver.
And here is the most important problem for anybody who wants to build
a useful remailer to think about:
* What is stopping you, today, from using these tools for _all_ your
email? For me, I would need <60 min latency, very high reliability,
a reply channel anybody could use, and reasonable confidence that my
address wouldn't get blackholed.
======================================================================
Legend:
SPEC!! - Not specified
SPEC - Spec not finalized
- Not done
* Top priority
. Partially done
o Done
D Deferred
X Abandoned
For a list of good beginner projects, check out HACKING.
NEEDS TO BE WRITTEN:
For 0.0.8:
o Better error messages on expired / not-yet-ready certificates,
no matter how hard OpenSSL makes it.
o Dummies and pinging
o Refactor ClientDirectory to be more modular
o Retrying needs to be per-destination, not per-packet.
o Implement per-destination queue
o Tests for per-destination queue
o Make MMTP delivery use per-destination queue.
o Test upgrade path.
o Implement pinging
o Generate pings
o Link padding
o One-hop pings
o Two-hop pings
o Log pings, failed connects, successful connects
o Grovel over ping logs as needed
o Generate statistics from logs; remember stats
across invocations.
o Tests for pinging
o Save stats to disk
o Make more ping parameters configurable.
o Fix how uptime is computed: handle edges of days correctly
o Performance/data examination: is disk use too insanely high?
o Too many constants in Pinger.py; fix them.
o Document code.
- More easy-to-parse output format.
- Feedback output format to directory implementation?
- Document config
- Describe how to replace sqlite with pg or mysql.
. Distributed directories
o Spec changes
D Statistics go in format?
o Specify intermediate/final formats
o Intermediate format is server list with signed vote
o Final is multi-signed server-list-with-votes.
o List of other good directories (clique is who?)
o URL layout.
- Configuration: where are the directory servers?
. Server
o Implement formats: gen and parse
o Implement generate-dir-with-votes
o Implement read-multi-dirs-with-votes
- Implement download-multiple-directories
o Implement compute-vote-and-sign
- Implement download-multiple-signed-dirs
- Implement add-one-more-sig
- Document how to run a directory
- Interface for scripting
- Mix
- Implement upload-to-multiple-directories
. Client
- Choose random URL
o Validate multiple signatures
- Which sigs are valid? Enough?
- Document how to change directory config
. Test everything
. Test generating and parsing vote directory
. Test computing result of vote
. Test generating consensus directory
. Test parsing consensus directory
- Test actual directory code.
. Bugs
o Make tests pass with bizarre umasks. (Try 0077, 0000,
etc.)
o Specify acceptable versions in config file for directory,
not in ServerList.py
o Make build process mention where to download openssl if
neither wget nor curl is found.
o Pinger crashes when servers leave the directory, or aren't
live in the directory.
- Let server admins configure return addresses with default
real-names, even if users can override.
- Make client run and unittests not die when there is no
thread module.
o Have -P *5 -t mbox:foo@server always always mean
-P *5,server -t mbox:foo
- Make generate-surb --status-fd output decoding-handle,
if that can be made secure.
o checkPathLength is great; somebody should invoke it. :/
- time.gmtime is *not* a precise inverse of calendar.timegm,
since the latter doesn't know about leapseconds. Fix this;
it can confuse the unit tests and maybe worse. We can
catch it by looking at time.gmtime(78969600) and seeing
whether we get (1972,7,3,0,0,0) or one second before.
o Regenerate SSL certificates more frequently.
o Drop support for pre-0.0.6 servers; Don't generate IPV4Info
any more.
- Use DB_RECOVER and DB_RECOVER_FATAL as appropriate
o Tolerate missing /dev/null
o Don't crash when calling mixminion clean-queue
- Documentation
- Make README and Makefile be clearer about how to proceed
when no openssl is found, and about option for local
install.
- Make README note that on some NetBSD systems, it's
necessary to add -I/usr/pkg/include. (Also tweak setup.py
to make CFLAGS more editable.)
Reach goals for 0.0.8:
- Specification
- Clear up specification for payload versions.
- Clear up specification for NEWS
- Make 'SIGHUP' reload, (and 'SIGUSR' dump).
- SIGHUP should reconfigure everything:
- Logs
- EventStats
- securedelete
- EntropySource (discard old entropy)
- Configuration (as used by key)
- File locations (????)
- Network setup
- Module setup
- (What else?)
- SIGHUP should check whether serverinfo should be
regenerated.
- Add SIGUSR1 to do rotate-and-dump only.
. Integrator help
- RFC822 interface to help integrators.
- "-o" option for queue
- "-i" option for flush.
- Maildir-style exit module to help integrators.
- Implement MH/Maildir modes
- Text/binary modes
- With/without decoding handle
- Attach to any type.
- For petmail:
- Working,well-designed --status-fd option
- For mnet:
o Implement trivial client side of client API
- Specify pluggable modules better.
- Consider server APIs
. Use a 'sendmail'-like program instead of a SMTP server,
optionally.
o Implement
- Test
Require for "0.1.0" (the in-theory-as-good-as-type-II release):
[Release criteria: Workable replacement for type II. At least as
anonymous, usable, secure, and portable. Other than lack of nymservers,
also ready to replace type I. Interfaces are stable enough that
integrators can start building GUIs and nymservers without expecting large
incompatible changes. Target: first half of 2004. (No guarantees!)]
- Security
- Upgrade packet format as necessary.
- Modules and module support
- Use STARTTLS as available, if it's not too hard.
- Real SMTP module
- Support multiple exit addresses. (cc, bcc, etc.)
Needs to be bandwidth-limited.
- Support NEWS
- End-to-end issues
- Minimal MIME support: allow headers; don't attempt to
enforce a single-best format.
- Configurability
- Better, documented support for http proxies for
downloading directories.
- Make DH parameter length configurable at 1024 bits
(or higher)?
. Freak out properly on missing/unpublishable IP.
. Full validation function for client
. Full validation function for server
- Support for non-clique topologies (cliques with a few
missing links would be sufficient.)
- Configurable number of threads to scale to multiple CPUs
- Client support
- Automatically remove old messages from client queue. (Add
'warn after' and 'delete after' configuration options'.)
- Avoid timing distinguishability attack related to
check-dir, gen-path, read-from-stdin: only download
directory *AFTER* reading? Strongly recommend a cron job?
Write the whole thing off as not-really-an-attack?
- Build and install process
- A well-tested 'make uninstall'
- RPMS, debs, and so on
. Make sure we run on solaris and *BSD.
. Make the software run under cygwin
- Installing to relative path
. An init.d script.
- Support for multiple directories, with automated agreement.
- Configurable dirserver fingerprints and URLs.
- Full documentation
- Complete docs for all code, with comments and examples.
- Write guide for module developers
- Write complete user's manual
- Complete all other docs
- History.
- Dummy messages (as in batching-taxonomy)
- DoS resistance strategy
- Timeout connections more aggressively under heavy load
- What else?
- Disable heinously insecure operating modes.
- Log which file has configuration; option to dump config
Other features for "1.0" (no research required):
- Full statistics
- Full statistics (ask Len what the list is.)
- Security
- Add ability to mark nodes as having same
administrative domain.
- Change pathgen to avoid two nodes with same domain
in a row.
- Change pathgen to avoid using same node for entry
and exit?
- Add jurisdictions to pathgen?
- Key management
- Document "server-DELKEYS"
- Password-protected private identity keys
- Password-protected private link/packet keys
- Password-protected dirserver keys
- There's no need to ever store MMTP keys to disk; we should
also rotate them more often. (Only if identity key is
unencrytped.)
- Better CLIs
- Add a --status-fd option similar to GPG's so that
we can be more easily embedded.
- Support for sending multiple copies of a packet?
- ClientAPI correctness
- Port ClientAPI from C API document.
- Move other functionality into ClientUtil module.
- ClientMain should only have CLI functionality.
- Heavy-duty performance/DoS testing
- Modules and module support
- MBOX
- Full config validation
- Full boilerplate text
- Tell ModuleManager about async code (as soon as needed)
- Configurability
- Make all filenames in server config relative to
server home, if not absolute.
- Support for one-side-only MMTP configurations.
- Make client-side pooling configurable and more
sophisticated.
- Separate error/other log files.
- Move boilerplate into outside files. Add some generic
'Boilerplate' functionality.
- Make SURB logging configurable.
- Add 'ALLOW' lines to blacklist.
- Client support
- Some way to read a reply block *and* a message from
stdin?
- Server UI functionality to inspect and clean out pools
- Port to Twisted, if reasonable (see HACKING)
- Send/receive large messages without having to suck them all
into RAM at once.
- Fragment and unfragment large messages on disk.
- MMTP / async
- Retrying should be per-destination, not per-packet.
Otherwise, we can leak which packets were first attempted
when.
- Limit number of packets sent over single client
connection.
- Tests for all cases:
- Packet to server with bogus IP
- Junk
- Retry on bogus close.
- Multiple senders
- Bad senders
- Bad recipients
- Hunt down leaks
- Testing
- Test on other (non-redhat, non-linux) systems
- COME UP WITH A REAL TESTING STRATEGY FOR PERFORMANCE AND
CLI'S AND MULTI-SERVER SITUATIONS.
- Integration tests
- Automated tests for several servers running
on one machine.
- Tests for servers on several different
machines.
- Repeatable CLI tests.
- For client
- For server
Features for "1.0" (some research/specification required):
- Nymservers
- Modules and module support
- Incoming email gateway
- Insert encoded packet into net.
- Reply to a reply block
- Configurability
- Make listening configurable for multiple ports/ips, not
all of which need be published. Perhaps allow different
rules for each listener. ???? Maybe not really a good idea.
- Client support: Improved path selection
- Watch out for servers that are really the
same server
- Only pick from the directory when picking
random servers.
- Notice Allow/Deny.
- Allow 'oneof' elements in paths.
- UI issues
- Notice when out of disk space, die more cleanly.
(support max-disk-usage).
- Dynamic IP support
- Servers redirect to latest IP if old IP is down. (Dynamic
IP support, after a fashion.)
- Client support: other
- Send message to user with known public key
- Real PKI for end-to-end encryption
- Directories
- Support for full-blown multiple-server agreement mechanism
- IPv6 support (must solve non-clique problem)
- Generate link padding (if it helps)
- Notice active attacks and block IPs dynamically.
- Abuse prevention of some undetermined kind.
WHEN WE GET THE CHANCE:
[This stuff could be for any version 1.0 or later; it's not a
requirement for 1.0.]
- License-friendliness:
- Switch from OpenSSL to NSS or GNUTLS
- GUI
- Security
- Memlockall wrapper
- Support for loopback fs automation and shredding.
- Make DB module choice configurable?
- Consider dropping support for older Python versions?
NEEDS TO BE BENCHMARKED
- TLS for leaks
- PEM for leaks
- gen_dh for leaks
- gen_cert for leaks