Nuke ‘MyFamily’

For reasons discussed in #5565 (moved), the ‘MyFamily’ option should go away:

• It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.
• Honest relay operators have a hard time setting MyFamily correctly on all of their relays.
• Relay family information bloats up microdescriptors, likely for no benefit.
• Groups of relays operated by the same entity can be recognized tolerably well (e.g. for metrics purposes) using their ContactInfo string instead (modulo the possible need for fuzzy matching of some sort).

This change requires (assuming I didn't forget anything):

• a proposal, spec change, and consensus method to remove relay family information from microdescriptors;
• a corresponding code change for Tor dirauths;
• a code change to clients to make them ignore relay family information (if they receive it, e.g. by turning off UseMicrodescriptors) by default, and warn if the user tries to re-enable use of relay family information without disabling UseMicrodescriptors.

changed milestone to %Tor: unspecified

added component::core tor/tor maybe-bad-idea milestone::Tor: unspecified needs-proposal parent::15060 path-selection points::5 priority::high research-program resolution::wontfix severity::normal status::closed tor-relay type::task labels

Replying to rransom:

• It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.

I've the feeling that this ignores the fact that MyFamily is still useful even if only honest operators use it. Why is it useful even then? 0wning a honest relay operator likely gives you access to all of his relays (sooner or later). [Yes after owning them the attacker could remove their MyFamily setting but reconfiguring and reloading a relay hopefully would rise some suspicion]

Or more generally: The probability to compromise relay A and B is higher if they are run by the same operator.

There are other concerns here, it wouldn't be trivial to match the two relays I'm running via contact info, and anyone can set up a relay matching my contact info, too. Generally the reasoning above uses "probably" too much imo.

I think the strongest argument we're going to get here will come from Tariq's research on guard rotational vulnerabilities. He found that when guard rotation occurs, the bad guy is significantly more likely to get his relay chosen as your guard if you obey the family stuff than if you ignore it. The 'significantly' is because a lot of our really big relays are in families. So there's increased vulnerability right now in the passive (no compromise of big nodes) case. The question is which vulnerabilities are worse.

I'm hoping to get good answers here once he finishes prepping the WPES paper/talk and moves on to the NDSS submission (or whatever venue is next).

Trac:
Cc: N/A to tariq.elahi@uwaterloo.ca, iang

Trac:
Keywords: N/A deleted, tor-relay added

Trac:
Component: Tor Relay to Tor

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: unspecified

Trac:
Keywords: tor-relay deleted, tor-relay needs-proposal added
Priority: normal to major

I think it is a bad idea to remove the family setting, because it will make larger operators a more interesting target.

What if I end up as both entry and exit, and potentially even the middle node? Some time ago, some LEA wanted me to give up information on a case that was "happening right now", so there might still be open circuits, right?

Replying to arma:

I think the strongest argument we're going to get here will come from Tariq's research on guard rotational vulnerabilities. He found that when guard rotation occurs, the bad guy is significantly more likely to get his relay chosen as your guard if you obey the family stuff than if you ignore it. The 'significantly' is because a lot of our really big relays are in families. So there's increased vulnerability right now in the passive (no compromise of big nodes) case. The question is which vulnerabilities are worse.

I'm hoping to get good answers here once he finishes prepping the WPES paper/talk and moves on to the NDSS submission (or whatever venue is next).

I talked to Tariq about this at Oakland, and he said that his analysis shows (counterintuitively) that taking away the Family concept actually doesn't change vulnerability to the above attacks much. That is, the 'significantly' above is not actually significant.

It would be interesting to have Aaron re-do the same calculation using his new TorPS simulator.

Trac:
Cc: tariq.elahi@uwaterloo.ca, iang to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703

Most ppl running more then 1 relay do not set this.

Trac:
Username: hsn

Trac:
Parent: N/A to #15060 (moved)

Worth looking at during 0.2.7 triage IMO

Trac:
Milestone: Tor: unspecified to Tor: 0.2.7.x-final

I'd like to know whether this applies to path selection too, or whether it only implies that we shouldn't consider families during guard selection. I'd also like to know whether it applies in a one-guard universe.

Trac:
Status: new to assigned

I believe it is dangerous to use all 3 relays in a circuit from a single entity - even if the entity is acting honestly.

MyFamily is hated and not properly used because:

1. it is cumbersome to manage

2. there are no incentives for a relay operator to set it properly

3. it was not easy to verify whether MyFamily was setup correctly on all your relays

4. I'm aiming to make it very easy for relay operators to manage MyFamily without them even knowing what MyFamily is (using an ansible role https://github.com/nusenu/ansible-relayor)

5. create a tor operator "bandwidth ranking" based on the family (new compass group-by family functionality). So a relay operator that wants to move up on the list has a reason to properly set MyFamily (using provided tools or manually). MyFamily is currently even the only way to properly group relays of a certain operator toghether. Using contactInfo is a much weaker since it does not require any mutual agreement.

6. relay operators can use compass to very easily verify whether their MyFamily is setup correctly using the Family lookup (which is already available today)

Trac:
Username: tyseom
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703 to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org

Trac:
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org, qbi

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: tor-relay needs-proposal deleted, needs-proposal, tor-relay, 027-triaged-1-out added

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Trac:
Username: rubiate
Sponsor: N/A to N/A
Severity: N/A to Normal
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org, qbi to tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org, qbi, cb@viennan.net

Re: comment #15 (closed)

2. there are no incentives for a relay operator to set it properly

Roster aims to fix this. http://tor-roster.org

For what it's worth, Roster also makes MyFamily a bit less painful to work with because the detected families are now robust to changes in the Family graph.  For details see:https://trac.torproject.org/projects/tor/ticket/16750

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, 027-triaged-in added

Trac:
Keywords: 027-triaged-in deleted, N/A added

Trac:
Keywords: 027-triaged-1-out deleted, N/A added

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

Trac:
Status: assigned to new

Trac:
Keywords: needs-proposal deleted, needs-proposal maybe-bad-idea path-selection research-program added
Points: N/A to 5
Reviewer: N/A to N/A

This ticket is mentioned in this proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/242-better-families.txt

Trac:
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, amj703, nusenu@openmailbox.org, qbi, cb@viennan.net to tariq.elahi@uwaterloo.ca, iang, gsathya, nusenu@openmailbox.org, qbi, cb@viennan.net

Trac:
Cc: tariq.elahi@uwaterloo.ca, iang, gsathya, nusenu@openmailbox.org, qbi, cb@viennan.net to tariq.elahi@uwaterloo.ca, iang, gsathya, nusenu@openmailbox.org, qbi, cb@viennan.net, phw

We implemented proposal 242, which obsoletes this ticket.

Future MyFamily improvements (or removals) should be proposed using the tor proposals process.

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed

changed time estimate to 40h

mentioned in issue #15060 (moved)

moved to tpo/core/tor#6676 (closed)

mentioned in issue tpo/core/tor#15060 (closed)