[tor-talk] How important is it that the MyFamily option be set correctly?
Pascal666 at Users.SourceForge.Net
Tue Dec 6 18:37:57 UTC 2011
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
There is an open request to add an include option to the config file
that may help to mitigate this:
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
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.
More information about the tor-talk