commit 90b7e19c07f0c7a8fb27680062de5942def5cf91 Author: Nick Mathewson nickm@torproject.org Date: Fri Feb 27 10:38:58 2015 -0500

Add proposal 242-better-families.txt --- proposals/000-index.txt | 2 + proposals/242-better-families.txt | 96 +++++++++++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index a1593a5..63317e1 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -162,6 +162,7 @@ Proposals by number: 239 Consensus Hash Chaining [DRAFT] 240 Early signing key revocation for directory authorities [DRAFT] 241 Resisting guard-turnover attacks [DRAFT] +242 Better performance and usability for the MyFamily option [OPEN]

Proposals by status: @@ -219,6 +220,7 @@ Proposals by status: 234 Adding remittance field to directory specification 236 The move to a single guard node 237 All relays are directory servers [for 0.2.6.x] + 242 Better performance and usability for the MyFamily option ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/242-better-families.txt b/proposals/242-better-families.txt new file mode 100644 index 0000000..f4ac620 --- /dev/null +++ b/proposals/242-better-families.txt @@ -0,0 +1,96 @@ +Filename: 242-better-families.txt +Title: Better performance and usability for the MyFamily option. +Author: Aaron Johnson, Nick Mathewson +Created: 2015-02-27 +Status: Open + +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 reach 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. +