Opened 7 years ago

Last modified 2 years ago

#5565 reopened enhancement

MyFamily should provide an alternate non-idhex subscription mechanism

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop242 tor-relay myfamily
Cc: rransom, tor-admin@…, nusenu@… Actual Points:
Parent ID: #15060 Points: 5
Reviewer: Sponsor:

Description

Everybody hates MyFamily. It's cumbersome, hard to update, hard to spot check that it's correct, and it gets in the way of vastly improving the practical security of the network through ephemeral identity keys (#5563).

So first off, what is wrong with making this PoS an arbitrary token ("OurFamily" anyone?) If weirdos start joining families that people don't want them to, can't we just de-list those nodes?

If we really can't handle the risk of people joining arbitrary families for any period of time, we could deploy a signature scheme where a node has to sign its IP+OrPort, current idhex, and/or nickname using a family key and place that signature into its MyFamily field.

We could even make this an incrementally deployable solution. We could first make the new field free-form, and then later update it to require authentication with a family key.

But my guess is this is not worth significant engineering, and we should just make it a free-form token and de-list nodes who try to adopt themselves into random families without consent.

Child Tickets

Change History (30)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final

Needs a proposal.

comment:2 Changed 7 years ago by nickm

Other options include having authorities put family-ids in the consensus, and letting them derive them from descriptors or extrainfos.

comment:3 Changed 7 years ago by mikeperry

Yeah, I guess before we even get to the proposal point: Can anyone think of any objections to doing this as KISS as possible, and making OurFamily an arbitrary 256bit identifier or something similar?

comment:4 Changed 7 years ago by nickm

Hm. Would there be a limit of declaring yourself to be in just one family? Currently, routers are in families on a pairwise basis: A and B are in the same family iff A says "MyFamily ...B..." and B says "MyFamily A." This allows each router to potentially be in any number of families.

I think that if you let nodes declare themselves to be in families, you need to limit how many they can be in. Otherwise, I can declare routers X,Y, and Z to be in all the families, and routers A,B,and C to be in no families. Any path that then gets built with X,Y, or Z is unusually likely to contain A,B,or C later in it.

If you can only declare one family? Hm. I'll try to brainstorm attacks a little more there when I wake up. Right now I am not thinking of anything epic.

comment:5 Changed 7 years ago by mikeperry

Cc: rransom added

Oh, now I see why you were appealing to the authorities to define family identifiers.

Yes, I was assuming there would be only one UUID number/token per family. You would not be able subscribe to multiple UUIDs. If two families wanted to merge, presumably it would be consensual and they would generate a new UUID.

comment:6 Changed 7 years ago by rransom

If you're worried about a relay's host obtaining a relay's secret keys, you can't rely on storing a relay family's secret key in its torrc or DataDirectory.

Should we worry about an attacker who compromises a relay's identity key being able to claim to be in that relay's families forever? If not, then an operator can generate a family-membership signature once per relay, put it in the relay's torrc, and have the relay put that signature in its descriptors (thereby cross-certifying it with the relay's identity key).

If we do worry about that replay attack, things get messier; a relay's operator will need to generate family-membership signatures once per $INTERVAL per relay, and then upload them to the relay periodically. (In this case, I wouldn't recommend putting the signature itself in the torrc; reference a separate file instead.)

Or should we just drop the MyFamily feature entirely, on the assumption that only good guys try to use it in a non-malicious way?

comment:7 Changed 7 years ago by rransom

(I should point out that we can use an elliptic-curve group with a 160-bit coordinate field here, so signatures fit in 320 bits with ‘point compression’, or 480 bits without it.)

comment:8 Changed 7 years ago by mikeperry

Replying to rransom:

If you're worried about a relay's host obtaining a relay's secret keys, you can't rely on storing a relay family's secret key in its torrc or DataDirectory.

Should we worry about an attacker who compromises a relay's identity key being able to claim to be in that relay's families forever? If not, then an operator can generate a family-membership signature once per relay, put it in the relay's torrc, and have the relay put that signature in its descriptors (thereby cross-certifying it with the relay's identity key).

Yeah, this is how we would do a family key deployment. The key would ideally be used to sign a statement offline once, and then that signed statement would be used for time period T.

However, I think we should first try to find issues with a simple UUID-based solution. Are there any?

If we do worry about that replay attack, things get messier; a relay's operator will need to generate family-membership signatures once per $INTERVAL per relay, and then upload them to the relay periodically. (In this case, I wouldn't recommend putting the signature itself in the torrc; reference a separate file instead.)

Hrmm.. Yeah, already the complexity mounts. I forgot about re-using old signatures and setting time limits/expiry. Thanks.

Or should we just drop the MyFamily feature entirely, on the assumption that only good guys try to use it in a non-malicious way?

Well, what about the UUID-based solution? Nick may or may not come up with attacks in his dreams. Can we think of any while we're awake? I am not seeing any, but I am also biased against complexity..

comment:9 in reply to:  8 ; Changed 7 years ago by rransom

Replying to mikeperry:

However, I think we should first try to find issues with a simple UUID-based solution. Are there any?

A ‘simple UUID-based solution’ doesn't handle the case of a relay administrable by two parties, each of whom also solely administers other relays. (This has actually happened.)

If we do worry about that replay attack, things get messier; a relay's operator will need to generate family-membership signatures once per $INTERVAL per relay, and then upload them to the relay periodically. (In this case, I wouldn't recommend putting the signature itself in the torrc; reference a separate file instead.)

Hrmm.. Yeah, already the complexity mounts. I forgot about re-using old signatures and setting time limits/expiry. Thanks.

I'm not sure we should care about this replay attack; I just mentioned it because someone had to.

The more important question is: Is MyFamily a good feature to keep?

comment:10 in reply to:  9 ; Changed 7 years ago by arma

Replying to rransom:

The more important question is: Is MyFamily a good feature to keep?

I've been tending toward 'no' lately. Some directions to consider:

  • Good guys set it, and bad guys don't.
  • It significantly reduces the available first-hop entropy (some of our big guards are in a family), thus improving attacks by bad guys who would sign up relays and hope you pick them as a guard.
  • The ability to observe and correlate at the network and upstream level, rather than relay level, is poorly understood and probably very important here.

comment:11 in reply to:  10 Changed 7 years ago by arma

Replying to arma:

  • It significantly reduces the available first-hop entropy

and last-hop entropy too

comment:12 in reply to:  3 Changed 7 years ago by arma

Replying to mikeperry:

Yeah, I guess before we even get to the proposal point: Can anyone think of any objections to doing this as KISS as possible, and making OurFamily an arbitrary 256bit identifier or something similar?

The design is "A relay, if it wants, can set a uuid in its descriptor. Any set of relays that pick the same uuid will never have more than one from the set appear in the same path"?

So if Moritz runs five fast relays, together making up 10% of the network by bandwidth, and puts them all in the same family, the adversary can set up a relay and tell clients "if you ever pick me, be sure never to pick any of Moritz's nodes in that path"? I don't have a specific attack in mind yet, but that sort of probability distribution shift makes me nervous. My first thought would be to argue for ditching the family concept rather than introducing this new approach and then waiting for somebody to flesh out the attack.

comment:13 Changed 7 years ago by rransom

Reasons to keep MyFamily include:

  • If someone administers many relays, they are likely to all have similar configurations, so there will be some attacks which compromise all relays in a family and would not compromise unrelated relays.
  • If someone administers many relays, he/she/it may want to reduce the amount of traffic which his/her/its relays could potentially correlate, in order to reduce the value of performing a rubber-hose attack. (But this doesn't work so well if people don't pay attention to MyFamily or if relay operators suck at setting it.)

More reasons to throw away MyFamily include:

  • The current implementation takes up a lot of space in relay descriptors, and presumably also in microdescriptors.
  • Adding a better implementation will take a lot of developer resources, and in particular, it will take a lot of my resources if you want to go for the 160-bit elliptic curve (rather than using the Curve25519 group and spending 512 or 768 bits per signature).

comment:14 in reply to:  13 Changed 7 years ago by rransom

Replying to rransom:

(rather than using the Curve25519 group and spending 512 or 768 bits per signature).

Note that these signature sizes are binary bits; multiply by at least 4/3 for the base64-encoded size that we would probably put in descriptors.

comment:15 Changed 7 years ago by torland

Cc: tor-admin@… added

comment:16 Changed 7 years ago by cypherpunks

I'm in favor to keep the MyFamily functionality (for reasons described by rransom).

Here is an alternative approach to build a family:

https://lists.torproject.org/pipermail/tor-dev/2012-August/003960.html
#6662

comment:17 in reply to:  16 Changed 7 years ago by rransom

Replying to cypherpunks:

I'm in favor to keep the MyFamily functionality (for reasons described by rransom).

I'm in favor of throwing it away (for the reasons that arma gave, and the microdescriptor-bloat reason).

comment:18 Changed 7 years ago by cypherpunks

I'm also in favor to keep MyFamily for transparency reasons and to improve overall tor network diversity.
Karsten will add a group by feature (#6662) to compass.torproject.org that might gives us a better understanding on family sizes and overall bandwidth share across the tor network.

comment:19 in reply to:  18 ; Changed 7 years ago by rransom

Replying to cypherpunks:

I'm also in favor to keep MyFamily for transparency reasons

You can use the ContactInfo string for that. (Just set it to the same value on each relay you operate.)

and to improve overall tor network diversity.

How can the MyFamily feature improve network diversity?

comment:20 in reply to:  19 Changed 7 years ago by cypherpunks

Replying to rransom:

Replying to cypherpunks:

I'm also in favor to keep MyFamily for transparency reasons

You can use the ContactInfo string for that. (Just set it to the same value on each relay you operate.)

Yes, I used it occasionally I'll suggest it as a compass feature.


and to improve overall tor network diversity.

How can the MyFamily feature improve network diversity?

Yes, it is true it does not help to improve network diversity directly. What I meant is to recognize associated relays and big relay operators. This information can be used to selectively support [1] relatively small operators.

[1] https://blog.torproject.org/blog/turning-funding-more-exit-relays

comment:21 Changed 7 years ago by rransom

Resolution: wontfix
Status: newclosed

Closing this ticket as ‘wontfix’, in favor of #6676 (‘Nuke ‘MyFamily’’), because there don't seem to be any compelling reasons to keep relay families (for the purposes for which they are currently used) for now.

comment:22 Changed 7 years ago by nickm

Resolution: wontfix
Status: closedreopened

Reopening; I am not convinced by #6676 yet.

comment:23 Changed 7 years ago by nickm

Keywords: needs-proposal added

comment:24 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:25 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:26 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

comment:27 Changed 4 years ago by nickm

Parent ID: #5563#15060

comment:28 Changed 4 years ago by nickm

Keywords: prop242 added; needs-proposal removed

There's a proposal for this, but see also #6676.

comment:29 Changed 4 years ago by tyseom

Cc: nusenu@… added

comment:30 Changed 2 years ago by nickm

Keywords: myfamily added
Points: 5
Severity: Normal
Note: See TracTickets for help on using tickets.