Opened 6 years ago

Last modified 11 months ago

#6676 new task

Nuke ‘MyFamily’

Reported by: rransom Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, needs-proposal maybe-bad-idea path-selection research-program
Cc: tariq.elahi@…, iang, gsathya, amj703, nusenu@…, qbi, cb@… Actual Points:
Parent ID: #15060 Points: 5
Reviewer: Sponsor:

Description

For reasons discussed in #5565, 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.

Child Tickets

Change History (30)

comment:1 in reply to:  description Changed 6 years ago by cypherpunks

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.

comment:2 Changed 6 years ago by Sebastian

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.

comment:3 Changed 6 years ago by arma

Cc: tariq.elahi@… iang added

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).

comment:4 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:5 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:6 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

comment:7 Changed 6 years ago by arma

Keywords: needs-proposal added
Priority: normalmajor

comment:8 Changed 5 years ago by mo

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?

comment:9 in reply to:  3 Changed 5 years ago by arma

Cc: gsathya amj703 added

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.

comment:10 Changed 5 years ago by hsn

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

comment:11 Changed 3 years ago by nickm

Parent ID: #15060

comment:12 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:13 Changed 3 years ago by nickm

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.

comment:14 Changed 3 years ago by nickm

Status: newassigned

comment:15 Changed 3 years ago by cypherpunks

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

1) 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)
2) 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.
3) relay operators can use compass to very easily verify whether their MyFamily is setup correctly using the Family lookup (which is already available today)

comment:16 Changed 3 years ago by tyseom

Cc: nusenu@… added

comment:17 Changed 3 years ago by qbi

Cc: qbi added

comment:18 Changed 3 years ago by nickm

Keywords: 027-triaged-1-out added

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

comment:19 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

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

comment:20 Changed 3 years ago by rubiate

Cc: cb@… added
Severity: Normal

comment:21 Changed 3 years ago by virgil

Re: comment #15

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

comment:22 Changed 21 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:23 Changed 20 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:24 Changed 15 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:25 Changed 15 months ago by nickm

Keywords: 027-triaged-in added

comment:26 Changed 15 months ago by nickm

Keywords: 027-triaged-in removed

comment:27 Changed 15 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:28 Changed 15 months ago by nickm

Status: assignednew

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

comment:29 Changed 15 months ago by nickm

Keywords: maybe-bad-idea path-selection research-program added
Points: 5
Note: See TracTickets for help on using tickets.