[tor-dev] Proposal 242: Better performance and usability for the MyFamily option

[Sebastian G. <bastik.tor>]

27.02.2015, 16:41 Nick Mathewson:

I had time to read it.


> [cut] 
> 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.

Assuming IFF is if and only if.

>    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.

Would be worse if the situation is not on the same level as before.

> [cut]
> 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.

s/For reach/For each/

> 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.

I had trouble seeing family being good in a 6 relay Tor network run by
two different entities (three relays each, one honest, one malicious),
because the family setting would make one use two malicious relays every
time. The question was how much does this change when the amount of
entities and the amount of relays increases.

BTW: With some ill-intent the quote "It's possible that families are a
bad idea entirely[.]" can be taken out of context by journalists.

Best Regards,
Sebastian G.