Relay flooding, confirmation, HS's, default relay, web of trust
Some further thoughts on an already mixed thread... Would this increase anonymity? As pointed out previously, not much. Attacks against Tor anonymity usually relate to entry-point/exit-point traffic correlation... Regardless of how many segments are in the middle, if your adversary can corner the market on exit nodes, it doesn't matter how many intermediate relay nodes you're using. (Correct me where I'm wrong, experts) Ahh, ok, I see, entry-exit correlation/tagging/timing/confirmation... interesting. I guess a longer path length could only help a quite tiny amount with that by adding some jitter, packet loss, dead circuit churn, etc in between. It certainly directly helps a lot against those entities trying to do simple hop by hop flow/log requests. Non-exit relay by default wouldn't help regarding the exit part as no one's suggesting turning up new exit relays by default. But it could add more guards making observing any useful subset of them costlier. But also make the less traffic in them more likely to be yours. And what if the oponnent runs a hidden service trap?... seems that then just watching or running the client's entry guard [1] is all that is needed to confirm both connection and content? Yipes?!!! I'm no expert. This sounds like a very hard and real problem. Thanks! [1] One single lucky node, not two, the trap serves as the exit watchpoint as well. Would this increase the health of the overall network? Yes*! Are there anonymity drawbacks to having a glut of available bandwith? Or a glut of legit nodes? Or both? I've not yet considered that in my suggestion of a model in which Tor can in fact be used for bulk/P2P transfer and remain resource healthy. Or, as mentioned earlier, we can assign an OR a level of trust commensurate with its age? Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. Degrees of separation could also be encoded, and no web is impenetrable. So it would be just one more means of scoring nodes. The sigs would be saying: Hey, I know this operator in real life or online. They have the skill to run an up to date, reasonably secure node and at least check for cold compromise once in a while. And I would be reasonably comfortable were my traffic to transit their node, excepting of course lawful order or coercion. As before, loose, just another means. Also, symmetry of up/down bandwidth can be an issue too... which is unfortunate. Issue? A non-exit relay runs the same bitrate in and out of its interface, bytes in, bytes out, over time, it's impossible not to. So your maximum giveback is limited to the lower of your asymmetrical rates because you'll saturate the slower side at any greater rate. The unfortunate thing about it is that all four of economies, tech, policies and outright supression conspire to make asymmetry what you see in the consumer market. As opposed to cable (and various RF tech and fiber PON's), fiber and dsl aren't really tech limited to asymmetry. So you're just seeing the other three in action there. Protest, buy more, or co-op and trench your own neighborhood :) s/hit/hip/ ;) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, 6 Dec 2010, grarpamp wrote: And what if the oponnent runs a hidden service trap?... seems that then just watching or running the client's entry guard [1] is all that is needed to confirm both connection and content? Yipes?!!! I'm no expert. This sounds like a very hard and real problem. Thanks! [1] One single lucky node, not two, the trap serves as the exit watchpoint as well. I'm too obtuse to understand, just with your footnote alone, what a hidden service trap is - would you provide a further explanation, or a link to one ? Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, Dec 06, 2010 at 05:18:21PM +, John Case wrote: I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... I think it is an excellent idea (I've suggested that much in the past IIRC). -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On 2010-12-06 09:18, John Case wrote: On Mon, 6 Dec 2010, grarpamp wrote: [...] Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. The WoT cannot provide security benefits to a group of users with no pre-existing social trust relationship, such as the set of Tor node operators. The thousands of Tor node operators, a tiny percentage of which have an existing social relationship, have no inherent trust amongst each other. And how could they? Absent an existing real-life WoT, there is no digital WoT to codify. Even within a group that has a strong existing trust and social graph in real life, the digital codification of a WoT offers security benefits only at the extreme margins. This fact is easiest explained by example: o Fire up your preferred OpenPGP software. (If you don't have OpenPGP software, then your understanding of how a WoT works is likely different from what a WoT actually does). o Eliminate all public keys for users with whom you do not intend to communicate. (No communication security system can provide security benefits to communications that will never take place). o List the public keys that show as valid. (Meaning they are signed by one or more keys that you trust to some degree). o Eliminate all the public keys that are signed by your key. (Those keys are not authenticated by the WoT, they were authenticated by you directly). o Eliminate all the public keys that are signed by keys that you chose to trust because they are the equivalent of CA root keys. This includes Debian distribution signing keys, the keys of any commercial CA, and the signing keys of auto-responder key servers such as the PGP Global Directory. (Signatures performed by such keys do not employ the WoT). o Look at the small number of public keys remaining. The keys are likely from deep inside your social circle. Now eliminate all the public keys that you could trivially authenticate directly, such as by asking a key holders, who are well known to you, to provide you with their key's fingerprint at work, at the next security conference, or the next time you meet at the pub. (The WoT may have authenticated those keys, but the WoT was not necessary to do so since you could have trivially authenticated those few keys yourself). o Lastly, count the remaining public keys. The number will likely be zero (no real life benefit to the WoT) or close to zero (benefit only in the extreme margins). In summary, the WoT is not a suitable solution to increasing the security of the Tor network. --Lucky Green *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, 6 Dec 2010, Lucky Green wrote: The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. Understood. I thik this is worth implementing as a feature - a handful of known nodes begets a handful^2 of trusted nodes, and pretty soon a relatively small organization has a relatively large trusted network. It may not be suitable for you, or for me, but it would be suitable for some... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
I'm too obtuse to understand, just with your footnote alone, what a hidden service trap is - would you provide a further explanation, or a link to one ? A hidden service trap is a hidden service run by any one/entity you'd rather not be doing business with. A trap, a lure, a ruse, a sting. Leading to possible incrimination, characterization, etc... bridging same into the non-anonymous real world. Could be a Bad/Good dude/thing, depending on your point of view. Lucky Green on WoT Oh yes, agreed, I never claimed signing into OpenPGP WoT was magic solution. I littered it with soft disclaimers. As before, it would be an *additional* metric which could optionally be used in selection calculations if desired. Save for a few, the node owners are mostly known only by IP. One might feel better if there was a human keychain wrapped around some of them. Many of us fully understand the weakness of such a WoT as applied to Tor, for which there's no requirement to elect to use its metrics. Much as one may or may not choose to utilize nodes that appear to reside in certain countries, appear to run on certain platforms, have cute nicknames, etc. Were I to be running a node, maybe I'd sign others based on whatever I felt they meant to me. Maybe others would similarly sign mine. Maybe the EFF would sign some, maybe Tor, maybe CCC, maybe torservers, maybe people on mailing lists, maybe FOSS devs, etc, the usual. And maybe I'd let degree of separation from me or them be a weighted guide as to the rest. It's just another tool to use, not magic. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
