[tor-talk] How important is it that the MyFamily option be set correctly?

[Pascal]

When an experienced operator like Moritz who actually reads this list 
and wants to configure this correctly is unable to do so, there is 
definitely something wrong.

Torservers.net apparently publishes their config file.  There appear to 
be a number of relays using this config file that are not associated 
with each other or Torservers.net.  How would your proposal be affected 
by this?

There is an open request to add an include option to the config file 
that may help to mitigate this: 
https://trac.torproject.org/projects/tor/ticket/2863

The current framework allows multiple operators to manage multiple 
overlapping nodes without forcing every node to be in the same family. 
For example, if operator A has access to nodes 1 and 2 and operator B 
has access to nodes 2 and 3, then currently nodes 1 and 3 do not need to 
be in the same family.  No idea if anyone actually uses it this way.

As long as a node need not and can not be in multiple families at the 
same time, is there really a need for the family string to be secret? 
The only reason that unidirectional associations are currently ignored 
is to prevent a node from claiming that every other node is in their 
family.  Does it really hurt anything if an unassociated node claims 
they are in your family alone?

 From the results of the script I just posted, it appears to be much 
more likely that ContactInfo will be set consistently across all nodes 
in a family than MyFamily will actually be set correctly.

Rather than supplanting the existing family system, I would suggest a 
secondary system be added.  A FamilyName (or similar) option be added to 
the config file.  If not set, ContactInfo would automatically be used in 
its place (not published as the FamilyName, but used in its place by 
anyone looking for a path).  Nodes would then avoid using two relays 
with the same FamilyName (or ContactInfo).  Note that a case insensitive 
alphanumeric match would probably be best.  Users do not always type the 
exact same thing into ContactInfo.

This way users who want their nodes associated but don't want to set 
ContactInfo can do so, existing bidirectional associations continue to 
work, and families automagically get created for anyone who did set 
ContactInfo.

-Pascal


On 12/5/2011 7:28 PM, Gregory Maxwell wrote:
> But it's N^2 work if you add servers one at a time, which is annoying
> and failure prone.
>
> It would be nicer if the family option took a secret string for each
> specified family that was hashed (e.g. via PBKDF2) and then used as a
> private key. Then the node ID is signed using that key (e.g. with
> ECDSA) and the signature is published in the directory.
>
> Nodes could then validate the signatures and then treat all nodes with
> the same public key as the same family. Because the security of this
> isn't terribly important a fairly small field could be used.
>
> This would make directories bigger for small families but smaller for
> big ones. It would avoid the constant update work and make it less
> likely that well meaning people would misconfigure.
>
> Sadly doing something like this w/ RSA would be very bloating.