-
Notifications
You must be signed in to change notification settings - Fork 84
/
242-better-families.txt
97 lines (70 loc) · 3.5 KB
/
242-better-families.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
Filename: 242-better-families.txt
Title: Better performance and usability for the MyFamily option
Author: Nick Mathewson
Created: 2015-02-27
Status: Superseded
Superseded-by: 321-happy-families.md
1. Problem statement.
The current family interface allows well-behaved relays to
identify that they all belong to the same 'family', and should
not be used in the same circuits.
Right now, this interface works by having every family member
list every other family member in its server descriptor. This
winds up using O(n^2) space in microdescriptors, server
descriptors, and RAM. Adding or removing a server from the
family requires all the other servers to change their torrc
settings.
One proposal is to eliminate the use of the Family option
entirely; see ticket #6676. But if we don't, let's come up with
a way to make it better. (I'm writing this down mainly to get it
out of my head.)
2. Design overview.
In this design, every family has a master ed25519 key. A node is
in the family iff its server descriptor includes a certificate of
its ed25519 identity key with the master ed25519 key. The
certificate format is as in proposal 220 section 2.1.
Note that because server descriptors are signed with the node's
ed25519 signing key, this creates a bidirectional relationship
where nodes can't be put in families without their consent.
3. Changes to server descriptors
We add a new entry to server descriptors:
"family-cert"
This line contains a base64-encoded certificate as described
above. It may appear any number of times.
4. Changes to microdescriptors
We add a new entry to microdescriptors:
"family-keys"
This line contains one or more space-separated strings describing
families to which the node belongs. These strings MUST be
between 1 and 64 characters long, and sorted in lexical order.
Clients MUST NOT depend on any particular property of these
strings.
5. Changes to voting algorithm
We allocate a new consensus method number for voting on these keys.
When generating microdescriptors using a suitable consensus
method, the authorities include a "family-keys" line if the
underlying server descriptor contains any family-cert lines.
For each family-cert in the server descriptor, they add a
base-64-encoded string of that family-cert's signing key.
6. Client behavior
Clients should treat node A and node B as belonging to the same
family if ANY of these is true:
* The client has server descriptors or microdescriptors for A
and B, and A's descriptor lists B in its family line, and
B's descriptor lists A in its family line.
* The client has a server descriptor for A and one for B, and
they both contain valid family-cert lines whose certs are
signed by the family key.
* The client has microdescriptors for A and B, and they both
contain some string in common on their family-cert line.
7. Deprecating the old family lines.
Once all clients that support the old family line format are
deprecated, servers can stop including family lines in their
descriptors, and authorities can stop including them in their
microdescriptors.
8. Open questions
The rules in section 6 above leave open the possibility of old
clients and new clients reaching different decisions about who is
in a family. We should evaluate this for anonymity implications.
It's possible that families are a bad idea entirely; see ticket
#6676.