MyFamily should provide an alternate non-idhex subscription mechanism
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 (moved)).
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.
Activity
changed milestone to %Tor: unspecified
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.
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.
Trac:
Cc: N/A to rransomIf 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?
-
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..
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?
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.
-
-
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.
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).
Trac:
Username: torland
Cc: rransom to rransom, tor-admin@torland.meI'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 (moved)
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).
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 (moved)) to compass.torproject.org that might gives us a better understanding on family sizes and overall bandwidth share across the tor network.
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?
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
Closing this ticket as ‘wontfix’, in favor of #6676 (moved) (‘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.
Trac:
Status: new to closed
Resolution: N/A to wontfix-
Reopening; I am not convinced by #6676 (moved) yet.
Trac:
Status: closed to reopened
Resolution: wontfix to N/A -
Trac:
Parent: #5563 (moved) to #15060 (moved) -
There's a proposal for this, but see also #6676 (moved).
Trac:
Keywords: needs-proposal tor-relay deleted, prop242 tor-relay added -
Trac:
Username: tyseom
Cc: rransom, tor-admin@torland.me to rransom, tor-admin@torland.me, nusenu@openmailbox.org mentioned in issue #6676 (moved)
mentioned in issue #15060 (moved)
moved to tpo/core/tor#5565 (closed)
mentioned in issue tpo/core/tor#6676 (closed)
mentioned in issue tpo/core/tor#15060 (closed)
