Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On 20.05.2010 13:28, Oguz wrote: I too do not understand this. Already an evil entry node can list all nodes that it does _not_ control in its family option to try to force circuit through the nodes it controls, though it would obviously be a dead give away listing many unrelated nodes as within the family. Is there a check when a node declares itself to be in a family the descriptor of the other family members are checked to confirm? From what I understand, yes, at the moment both partners have to list each other. That's what the fuss is all about, because this becomes hard to manage when you run a lot of nodes. -- Moritz Bartl GPG 0xED2E9B44 http://moblog.wiredwings.com/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 01:31:47PM +0200, t...@wiredwings.com wrote 0.9K bytes in 19 lines about: : From what I understand, yes, at the moment both partners have to list : each other. That's what the fuss is all about, because this becomes hard : to manage when you run a lot of nodes. Yes, this is how MyFamily works. Each node in the family must be configured to list all other nodes in the family. If I start up node Alice, and list Bob and Mallory in MyFamily, Bob must list Alice and Mallory, and Mallory must list Alice and Bob. If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. Or list all nodes in the network but 3 and shunt all traffic through those 3, etc. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 07:44:51AM -0400, and...@torproject.org wrote: On Thu, May 20, 2010 at 01:31:47PM +0200, t...@wiredwings.com wrote 0.9K bytes in 19 lines about: : From what I understand, yes, at the moment both partners have to list : each other. That's what the fuss is all about, because this becomes hard : to manage when you run a lot of nodes. Yes, this is how MyFamily works. Each node in the family must be configured to list all other nodes in the family. If I start up node Alice, and list Bob and Mallory in MyFamily, Bob must list Alice and Mallory, and Mallory must list Alice and Bob. If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. Or list all nodes in the network but 3 and shunt all traffic through those 3, etc. Glad I read this thread through to the end. This was what I was going to say, only not as well as Andrew. It is possible however, to have some value to allowing some asymmetry, viz: if Alice lists Bob_1, ..., Bob_1000 in her family, but no Bob lists Alice, then a path selection that chooses both Alice and Bob_i will be rejected, but one that lists Bob_i and Bob_j will be just fine. This is not how MyFamily works now (or am I wrong ?). But that could change. The only paths Alice could then affect would be ones that choose her. The point is not just that the attacks Andrew mentioned are no longer possible. It is also true that someone who mananged to set MyFamily on only some of his nodes would still cause those paths to be avoided. S/he may or may not have covered the entire family by this process, but s/he can cover the entire family by setting MyFamily in half of them, perhaps a little less overhead. Perhaps this is what various people were alluding to when they said that there is no attack in letting one node set MyFamily and having it only affect itself thereby? The above is not an unqualified recommendation, however. Besides the fifty percent configuration overhead savings for people with large families. I like that a partially set family provides some of the intended function rather than just failing completely, but (a) It's off the top of my head, (b) There may be other more subtle attacks than the obvious ones Andrew was mentioning, (c) The added complexity of it being OK to do something less complete than setting this at all nodes may lead to more people getting it wrong more often so that the graceful failure is more than offset. (d) I haven't thought about implications for complexity of path selection, distribution of directory info, etc. They may render any benefit too expensive. All that said, it is perhaps worth at least considering. aloha, Paul *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On 20 May 2010 07:44, and...@torproject.org wrote: If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. Why would this screw everyone? I admit that I don't fully understand how families are implemented, however, this doesn't seem sensible to me. Under a scheme which allowed ``one-sided family declarations'' this doesn't seem to be the ideal behaviour. If Mallory lists all the nodes in the network, then this should prevent all the paths which have Mallory somewhere in them, but not paths which avoid her entirely. An aggressive family declaration by Mallory only prevents her from getting traffic, without impacting the rest of the network.This would seem to be the only sensible way to implement ``one-sided family declarations'', to prevent exactly the problem described.
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On May 20, 2010, at 08:39 AM, Flamsmark wrote: On 20 May 2010 07:44, and...@torproject.org wrote: If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. Why would this screw everyone? I admit that I don't fully understand how families are implemented, however, this doesn't seem sensible to me. Under a scheme which allowed ``one-sided family declarations'' this doesn't seem to be the ideal behaviour. If Mallory lists all the nodes in the network, then this should prevent all the paths which have Mallory somewhere in them, but not paths which avoid her entirely. An aggressive family declaration by Mallory only prevents her from getting traffic, without impacting the rest of the network.This would seem to be the only sensible way to implement ``one-sided family declarations'', to prevent exactly the problem described. The problem I see with this is that it requires some foresight and backtracking in the creation of tunnels, which will add to network strain, unless someone can suggest a way to plan out the tunnels ahead of time.
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thursday May 20 2010 09:39:00 Flamsmark wrote: On 20 May 2010 07:44, and...@torproject.org wrote: If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. Why would this screw everyone? If only one side could declare a valid family that clients honored, you can control the paths clients choose. Eventually, some large percent of the network will find your declaration and be unable to build paths because they are all in the one-sided MyFamily declaration. Or, worse off, you run three nodes, let's call them TheMan0, TheMan1, and TheMan2. All three nodes list every other node in the network, except your three TheMan# nodes. Now as clients find your MyFamily declaration, they can only build paths through TheMan0, TheMan1, and TheMan2. Now you've won. This is one reason why the MyFamily declaration has to be the same on both sides in order for clients to honor it. Tor clients do not trust the Tor network by design. There are flaws in the MyFamily scheme, as we're seeing with perfect-privacy. It's a pain in the ass if you run a lot of nodes, so you just don't bother. It also assumes an honest relay operator will list all of all the nodes that should be in a MyFamily declaration. Right now, Tor won't use any relays in a circuit in the same /16 network to try to address network closeness of relays. We saw it was plausible that someone can start up a bunch of relays in the same datacenter in the same netblock and start to see a lot of circuits within that netblock. You can disable this behavior by setting EnforceDistinctSubnets to 0. It is an open and active area of research as to the degree of anonymity (increase or decrease) one receives as you develop trusted paths through the network (pick your own path), or Autonomous System aware paths, or country level aware paths, etc. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 1:31 PM, Moritz Bartl t...@wiredwings.com wrote: On 20.05.2010 13:28, Oguz wrote: I too do not understand this. Already an evil entry node can list all nodes that it does _not_ control in its family option to try to force circuit through the nodes it controls, though it would obviously be a dead give away listing many unrelated nodes as within the family. Is there a check when a node declares itself to be in a family the descriptor of the other family members are checked to confirm? From what I understand, yes, at the moment both partners have to list each other. That's what the fuss is all about, because this becomes hard to manage when you run a lot of nodes. A two-line shell script run automatically with ssh? 1) sed -i 's/^MyFamily .*/MyFamily [new servers]/' /etc/tor/torrc 2) killall -HUP tor Difficult? Come on, this can all be automated in 10 minutes if they keep a list of the servers they have access to. If you're already operating multiple servers, you will need to have methods like this anyway, when other things change. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
Oh. My. Goodness. Gracious! I go to sleep for a few hours, and the discussion descends into total confusion because a number of participants, including some tor developers, did not bother to read the proposal by Bruce from perfect-privacy.com. He did *not* propose, for example, any equivalent to #include statements. He did *not* propose, for example, any method of allowing a node to specify other members of a Family. Let's see if we can get the discussion back on track. Please read below carefully. On Thu, 20 May 2010 10:44:44 -0400 Andrew Lewman and...@torproject.org wrote: On Thursday May 20 2010 09:39:00 Flamsmark wrote: On 20 May 2010 07:44, and...@torproject.org wrote: If Mallory lists Alice and Bob, but neither Alice nor Bob list Mallory, it's not a valid Family. Otherwise, Mallory could list every node in the network and screw everyone. That was not Bruce's proposed method. Please go back and read it carefully. Why would this screw everyone? If only one side could declare a valid family that clients honored, you can control the paths clients choose. Eventually, some large percent of the network will find your declaration and be unable to build paths because they are all in the one-sided MyFamily declaration. Or, worse off, you run three nodes, let's call them TheMan0, TheMan1, and TheMan2. All three nodes list every other node in the network, except your three TheMan# nodes. Now as clients find your MyFamily declaration, they can only build paths through TheMan0, TheMan1, and TheMan2. Now you've won. Bruce's proposal prevents any such possibility because it does not allow specification of any nodes by Nickname, key fingerprint, or any other method. Rather, it allows a node to identify a Family by some Family name or other label of which it itself is a member. Alice runs nodes A1, A2, and A3. In the torrc file of each would be a line like MyFamily We'reOff Bob runs nodes B1, B2, B3, and B4. Each of his nodes' torrc files contains a line like MyFamily toSee Carol runs nodes C1 and C2. Both of these nodes' torrc files contain the following line. MyFamily theWizard Now, Dave has a client that downloads the descriptors for all of Alice's, Bob's, and Carol's nodes. Seeing the Family name each node says it belongs to, the client groups Alice's nodes into one Family, Bob's nodes into another Family, and Carol's nodes into a third Family. Dave's client then chooses routes for circuits that will use no more than one node from each Family, just as clients do now. If Ed comes along and fires up a node E1 that says, I'm in toSee Family, then if Dave's client chooses E1 for a route, it will not choose any of Bob's nodes for other positions in the same route. Likewise, if Dave's client chooses any of Bob's nodes for a circuit, Ed's E1 node will not be used for other positions in the same circuit. Ed, however, has no way to force Dave's client to choose Ed's nodes for circuit routes. This is one reason why the MyFamily declaration has to be the same on both sides in order for clients to honor it. Tor clients do not trust the Tor network by design. There are flaws in the MyFamily scheme, as we're seeing with perfect-privacy. It's a pain in the ass if you run a lot of nodes, so you just don't bother. It also assumes an honest relay operator will list all of all the nodes that should be in a MyFamily declaration. Again, that is completely inapplicable and irrelevant to Bruce's proposed method. To reiterate, his method enables each node to tell clients, I'm in Family xyz. Don't use more than one of us in a circuit. It does not allow any node to specify other nodes. A node simply specifies the name of a Family to which it belongs. Jeesh. It's really not very difficult, and no, it is not vulnerable to the sort of attack you, Roger, and Sebastian have now misdirected the discussion. Sigh. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 01:44:36PM -0500, Scott Bennett wrote: Oh. My. Goodness. Gracious! I go to sleep for a few hours, and the discussion descends into total confusion because a number of participants, including some tor developers, did not bother to read the proposal by Bruce from perfect-privacy.com. He did *not* propose, for example, any equivalent to #include statements. He did *not* propose, for example, any method of allowing a node to specify other members of a Family. Your interpretation of what Bruce said makes sense. But it is not how I parsed, BelongToFamily xyz in his message. I read it the same way it seems that Roger did, as giving a list: node x, node y, and node z. And then we're off and running. I think what Bruce/you suggest is better than what I proposed to avoid the problems Roger and Andrew noted. As I said before, it's not how MyFamily now works. And I believe Andrew/Roger/me/others were addressing trying to use the existing functionality in a different way, which was another disconnect. Anyway, this is certainly an idea worth considering. Now, should you ever say you are in multiple families at once? And should there be a lattice structure for families, hmmm? ;) Thanks for clearing things up, Paul *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
Hi Paul, On Thu, 20 May 2010 15:12:38 -0400 Paul Syverson syver...@itd.nrl.navy.mil wrote: On Thu, May 20, 2010 at 01:44:36PM -0500, Scott Bennett wrote: Oh. My. Goodness. Gracious! I go to sleep for a few hours, and the discussion descends into total confusion because a number of participants, including some tor developers, did not bother to read the proposal by Bruce from perfect-privacy.com. He did *not* propose, for example, any equivalent to #include statements. He did *not* propose, for example, any method of allowing a node to specify other members of a Family. Your interpretation of what Bruce said makes sense. But it is not how I parsed, BelongToFamily xyz in his message. I read it the same way it seems that Roger did, as giving a list: node x, node y, and node z. And then we're off and running. I think what Bruce/you You parsed xyz as meaning x,y,x or perhaps x y z? How bizarre. Even the current MyFamily statement doesn't do that. suggest is better than what I proposed to avoid the problems Roger and Andrew noted. As I said before, it's not how MyFamily now works. And I No, indeed it's not. Bruce was proposing an alternative method, one that looks far more sensible than the current method. believe Andrew/Roger/me/others were addressing trying to use the existing functionality in a different way, which was another disconnect. Anyway, this is certainly an idea worth considering. Now, should you ever say you are in multiple families at once? That's an interesting question, and I'm not sure of the answer. However, it's worth noting that it would not open any useful attack because each time a node adds itself to a Family reduces by some amount its probability of being selected for a route. And should there be a lattice structure for families, hmmm? ;) Not sure what that would accomplish. Seems to me that a client would maintain a list of Family names that it has encountered. Each time it encounters a descriptor with a Family name not already present in its list, it would add a new entry for that Family to the list. Each node claiming membership in a Family would have an membership entry linked off of the appropriate entry in the Family list. When a new descriptor for a node is encountered, it would be checked for Family designation(s) against the appropriate membership list(s) to see whether the membership list(s) should be updated. If a node vanishes from the directory, its memberships should be removed. If an entry in the Family list ends up with no membership entries linked from it, then that Family entry should be removed from the Family list. It's just mundane list maintenance stuff. Shouldn't be a big deal. Each node's descriptor entry in tor's internal representation of the directory would link directly to the appropriate Family list entry. If multiple Family designations are permitted for a node, then the internal directory entry would instead anchor a short list of pointers to the Family list entries. I suppose a bit could be reserved somewhere nearby that would say whether the field in the internal directory entry were a direct pointer or a list anchor in order to accommodate the most likely case, namely, that a node would be a member of, at most, a single Family. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 02:36:01PM -0500, Scott Bennett wrote: Hi Paul, On Thu, 20 May 2010 15:12:38 -0400 Paul Syverson syver...@itd.nrl.navy.mil wrote: Your interpretation of what Bruce said makes sense. But it is not how I parsed, BelongToFamily xyz in his message. I read it the same way it seems that Roger did, as giving a list: node x, node y, and node z. And then we're off and running. I think what Bruce/you You parsed xyz as meaning x,y,x or perhaps x y z? How bizarre. Even the current MyFamily statement doesn't do that. Right. But I only saw the message in the context of Roger's reply where he seems to have read it that way. To be generous, he was reading an email proposing something associated with MyFamily, not code. Also, in my experience 'xyz' (with or without spaces) is usually used to mean a list of things rather than as a name variable like 'foo'. To be even more generous, hey we all make mistakes and I've probably explored this mistake's origins a fair amount farther than interesting or productive. So stopping now. suggest is better than what I proposed to avoid the problems Roger and Andrew noted. As I said before, it's not how MyFamily now works. And I No, indeed it's not. Bruce was proposing an alternative method, one that looks far more sensible than the current method. I totally agree, albeit having not thought long or hard about it. Again, partly I was simply trying to explain to myself and perhaps others how we managed to misread the suggestion. believe Andrew/Roger/me/others were addressing trying to use the existing functionality in a different way, which was another disconnect. Anyway, this is certainly an idea worth considering. Now, should you ever say you are in multiple families at once? That's an interesting question, and I'm not sure of the answer. However, it's worth noting that it would not open any useful attack because each time a node adds itself to a Family reduces by some amount its probability of being selected for a route. And should there be a lattice structure for families, hmmm? ;) Not sure what that would accomplish. Seems to me that a client This and my other question were meant as jokes. Hence the emoticon. (Some of us haven't slept recently and are a bit punchy.) But yeah, many a theorem or system design started as jokes while goofing around. -Paul *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 01:44:36PM -0500, benn...@cs.niu.edu wrote 4.7K bytes in 91 lines about: : including some tor developers, did not bother to read the proposal by Bruce : from perfect-privacy.com. He did *not* propose, for example, any equivalent : to #include statements. He did *not* propose, for example, any method of : allowing a node to specify other members of a Family. You are correct. I did not respond to Bruce's proposal. I attempted to explain how MyFamily works today, and some of the risks of a client trusting the MyFamily statement from any one member of the family. This was suggested by others and there seems to be confusion around it. I am not addressing Bruce's proposal. I leave that to Paul, Roger, and others more qualified. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)
On Thu, May 20, 2010 at 08:50:00PM +0200, bacardic...@gmail.com wrote 1.1K bytes in 28 lines about: : Would it be possible for my to include myself in the MyFamily line? Yes. When I ran 10 nodes, this is what I did. One config for all 10 was easier to maintain than 10 unique configs. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
