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
|
How to hand out bridges.
Divide bridges into 'strategies' as they come in. Do this uniformly
at random for now.
For each strategy, we'll hand out bridges in a different way to
clients. This document describes two strategies: email-based and
IP-based.
0. Notation:
HMAC(k,v) : an HMAC of v using the key k.
A|B: The string A concatenated with the string B.
1. Email-based.
Goal: bootstrap based on one or more popular email service's sybil
prevention algorithms.
Parameters:
HMAC -- an HMAC function
P -- a time period
K -- the number of bridges to send in a period.
Setup: Generate two nonces, N and M.
As bridges arrive, put them into a ring according to HMAC(N,ID)
where ID is the bridges's identity digest.
Divide time into divisions of length P.
When we get an email:
If it's not from a supported email service, reject it.
If we already sent a response to that email address (normalized)
in this period, send _exactly_ the same response.
If it is from a supported service, generate X = HMAC(M,PS|E) where E
is the lowercased normalized email address for the user, and
where PS is the start of the currrent period. Send
the first K bridges in the ring after point X.
To normalize an email address:
Start with the RFC822 address. Consider only the mailbox {???}
portion of the address (username@host). Put this into lowercase
ascii.
Questions:
What to do with weird character encodings? Look up the RFC.
Notes:
Make sure that you can't force a single email address to appear
in lots of different ways. IOW, if nickm@freehaven.net and
NICKM@freehaven.net aren't treated the same, then I can get lots
more bridges than I should.
Make sure you can't construct a distinct address to match an
existing one. IOW, if we treat nickm@X and nickm@Y as the same
user, then anybody can register nickm@Z and use it to tell which
bridges nickm@X got (or would get).
Make sure that we actually check headers so we can't be trivially
used to sapam people.
2. IP-based.
Goal: avoid handing out all the bridges to users in a similar IP
space and time.
Parameters:
T_Flush -- how long it should take a user on a single network to
see a whole cluster of bridges.
N_C
K -- the number of bridges we hand out in response to a single
request.
Setup: using an AS map or a geoip map or some other flawed input
source, divide IP space into "areas" such that surveying a large
collection of "areas" is hard. For v0, use /24 adress blocks.
Group areas into N_C clusters.
Generate nonces L, M, N.
Set the period P such that P*(bridges-per-cluster/K) = T_flush.
Don't set P to greater than a week, or less than three hours.
When we get a bridge:
Based on HMAC(L,ID), assign the bridge to a cluster. Within each
cluster, keep the bridges in a ring based on HMAC(M,ID).
When we get a connection:
If it's http, redirect it to https.
Let net be the incoming IP network. Let PS be the current
period. Compute X = HMAC(N, PS|net). Return the next K bridges
in the ring after X.
3. Open issues
Denial of service attacks
A good view of network topology
|
