[tor-dev] putting 'Nuke MyFamily' to vote (#6676)

[Tim Wilson-Brown - teor]

> On 16 Apr 2016, at 17:13, Virgil Griffith <i at virgil.gr> wrote:
> 
> I'm not wholly in favor of keeping MyFamily in its current form.  In Roster we simply need a way to identify when two relays are owned by the same operator.  Worst comes to worst we could use the email address in the ContactInfo, or some such.

Some operators use a variant email address or ContactInfo for each relay, although these are in the minority.
Others don't have any ContactInfo at all.
I'm not sure whether any of these relays declare MyFamily or not, I'd have to check.

I'd like to know how many relay associations we'd lose in the current network by removing MyFamily before we make a decision.

> There have been proposals to do more creative signature schemes for MyFamily ownership.  This would also be a satisfactory solution.

I wonder if this kind of complexity would be worth it.
Do we gain much over the current system by using a signature scheme?
(Apart from making large families shorter and easier to administer, at the cost of making small families longer.)

> In summary, my world would not end if MyFamily ceased to exist----we'd simply use the ContactInfo for family membership.  Obviously family membership then becomes spoofable, but perhaps who cares?

It makes some difference for fallback directories, where we use a combination of family, contact, and IP to work out which relays are more likely to go down at the same time.

I also wonder about the impact on path selection and client security - even an honest operator can have their relays compromised or be compelled to provide information.

Tim


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160417/ef7cd960/attachment.sig>