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.
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk