Re: [tor-dev] [tor-relays] Hidden service policies
On Sun, Jul 20, 2014 at 9:57 PM, Thomas White thomaswh...@riseup.net wrote: Mike Hearn, Simple. If you start filtering anything at all, regardless of what it is ... then I will block any connection of your relays to mine ... Freedom isn't free unless it is totally free and a selective reading policy through Tor is not just a bad idea as stated below, I find it outright insulting to me and everyone else who cares about the free and open internet. The fact somebody has the audacity to come to a project like Tor and propose blacklisting mechanisms is jaw-dropping. ... As I recall, you are also the person who raised the idea of coin tinting or a similar concept in the bitcoin community to identify suspect coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 so while you are reading this, let me know if you run any relays so I can avoid them. router riker 207.12.89.16 9001 0 0 fingerprint 8657 6CF6 AA84 496F 62C0 5AFE 9F26 8962 A5F0 B2BD contact Mike Hearn m...@plan99.net accept *:8333 reject *:* Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
One of my first concerns would be that this would build in a very easy way for a government (probably the US government) to compel Tor to add in a line of code that says If it's this hidden service key, block access. And people who run Tor could easily take it out again, what with it being open source and all. After all - it's a stretch to say You must modify your software to support blocking things[0] I don't believe it's a stretch. If I did, perhaps I wouldn't bring the topic up. Judges and lawmakers care very little about the (in their eyes) minor distinction between the code to do this wasn't written yet and the code to do this wasn't configured yet. For example, look at the EU right to be forgotten ruling. The fact that no infrastructure existed to sift through tens of thousands of vague requests for search results to be removed didn't faze the court one bit, nor did the massive size of the project that resulted. They simply interpreted the (vague, poor) law put in front of them. Regardless, even if there is such a difference, jurisdiction would still have the same effect as today. If there's even one relay that supports introductions to a HS then the protocol would still technically work, but operators in regions where the government proved unfavourable would be protected and still able to operate. Additionally, in the absence of government coercion, the Tor relay community would then be able to collectively decide if they really want to pay for the privilege of giving bandwidth to botnet and ransomware operators. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
This isn't about 'acceptable usage of Tor', this is necessary compromise to limit exit operators' exposure to ISP harrassment. Even if we accept your premise that no exit operator cares about internet abuse, it's still the same thing. ISP's define what is acceptable usage of their internet connections and by implication, what is acceptable usage of the Tor exit. Tor could ignore what ISPs want (which is usually quite reasonable), but then no Tor clauses in ISP acceptable usage policies would just become even more prevalent. The ability to do this implies the ability for intro points to learn the identity public keys of hidden services they are introducing. Unfortunately, I believe this sort of enumeration attack is possible with the current HS protocol, but I think proposal 224 will fix it. It is currently possible and I am aware of proposal 224, which is why I'm bringing this up now. I don't think this is something that should be fixed without a *lot* of thought given to the consequences. I am by the way quite aware of all the counter arguments already, but someone has to play the devil's advocate here. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
On 07/21/2014 12:34 AM, Mike Hearn wrote: Tor provides exit policies to let exit relay operators restrict traffic they consider to be unwanted or abusive. In this way a kind of international group consensus emerges about what is and is not acceptable usage of Tor. For instance, SMTP out is widely restricted. As Andrea said, the exit policies are there mostly to have a small knob to stop complaints. In that sense, participation as a hidden service is opt-in: You're willing to lose the ability to use IP address as a rough method of identifying users. A network provider should in an ideal world _never_ [be able to] interfere with any of the traffic they transport. I already feel very uncomfortable limiting arbitrary destinations based on IP and port. A network provider is a neutral channel. Remember, data payload is just protocol overhead. -- Moritz Bartl https://www.torservers.net/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-relays] Hidden service policies
As I recall, you are also the person who raised the idea of coin tinting or a similar concept in the bitcoin community to identify suspect coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 I don't agree that it backfired. Yes, some people didn't like such discussions at all. Other people did though (I got a lot of fan mail for starting that discussion). If you think there's some kind of iron-clad consensus on these topics you need to leave your mailing lists and go talk to the general public, or heck, just try counting the number of services that are blocking Tor because of how it's being abused. Historically the crypto community has pursued absolute unbreakability and absolute privacy at all costs, including mainstream acceptability. This rendered its mathematical capabilities irrelevant. When Snowden wanted to talk to Greenwald using PGP he couldn't do it because PGP sucks so badly. The failure doesn't get more epic than that. The rare crypto products that are both strong and usable end up in an under-explored area: how tolerant is society of the resultant abuse? Tor is finding out the hard way that you don't need government coercion to end up widely shunned. Even the developers own IRC network is now blocking Tor. Gregory Maxwell has described Tor as heading towards a read only web, and he's not wrong. This inherently limits its mainstream appeal and weakens the anonymity loves company principle it relies on for protection. If we're going to make crypto both strong and mainstream, then the community needs to start thinking through the consequences of that for society at large. Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking? I allow only Bitcoin exit traffic because I have no desire to get raided because someone abused my exit. Currently regular Tor doesn't really exit any traffic through that node because it speculatively builds circuits to exits on the assumption they'll be used for web browsing, but we're in the process of integrating Orchid into bitcoinj (actually it's done but Orchid has a few bugs). So at some point Bitcoin wallets will start using Tor and they will know to build circuits to any exit that can support 8333. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Typos in 224-rend-spec-ng.txt
Hi All, I've found a few typos in the first few sections of 224-rend-spec-ng.txt at https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt I tried finding an existing bug or wiki entry on trac to log these against, but I couldn't find anything relevant with: https://trac.torproject.org/projects/tor/search?q=proposal+264 The typos are: (I read from the start to Section 2.2.3) Line 392, S 1.3, [IMD:AC]: 'knowledge od the contents' (knowledge *of* the contents) Line 618, S 2.2.1, [TIME-PERIODS]: 'a single set of hidden service directory' (*directories*) S 2.2.3. Where to publish a service descriptor: Line 702 : 'hsdir_n_replicas' should be 'n_replicas' to be consistent with lines 710-711: 'where n_replicas is determined by the consensus parameter hsdir_n_replicas' Line 733: An HSDir should rejects a descriptor (should *reject*) Hope this helps. Tim ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Typos in 224-rend-spec-ng.txt
Tim: I've found a few typos in the first few sections of 224-rend-spec-ng.txt at https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt Feel free to provide your fixes in the form of a patch. `git format-patch` can help crafting an email. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
On Mon, 2014-07-21 at 11:48 +0200, Mike Hearn wrote: One of my first concerns would be that this would build in a very easy way for a government (probably the US government) to compel Tor to add in a line of code that says If it's this hidden service key, block access. And people who run Tor could easily take it out again, what with it being open source and all. You're an intelligent person and probably know that it's more complicated than that. Any automatically updating mechanism to retrieve the Hidden Service Censorship List is a massive attack vector, because two clients having two different sets of introduction points for a hidden service, or two hidden services having different sets of introduction points available, causes a partition in the anonymity set. Regardless of the moral arguments you put forward, which I will not comment on, it seems like this idea would never be implemented because none of the Tor developers have a desire to implement such a dangerous feature. If you've already thought of this, as you implied in another email, why bring it up? Do you think you'll get the Tor community to agree to enable such a damaging attack? Further, why do you think such infrastructure would be remotely successful in stopping botnets from using the Tor network? A botnet could just generate a thousand hidden service keys and cycle through them. So, this would be: * Socially damaging, because it would fly in the face of Tor's anti-censorship messaging * Technically damaging, because it would enable the worst class of attacks by allowing attackers to pick arbitrary introduction points * Not technically helpful against botnets, because they can just cycle keys * Not even technically helpful against other content, because they can change addresses faster than volunteers maintaining lists of all the CP onionsites can do the detective work (which you assume people will want to do, and do rapidly enough that this will be useful) Let's skip all the devil's advocate discussion. It isn't useful and it'll cause traffic on this thread to blow up more than it already has. Instead, why don't you just present the strongest counterarguments you've thought of against this proposal, which surely include the above, and then the strongest counterarguments to those arguments, which justify your position and have caused you, as an intelligent person, bearing all those negative effects in mind, to *still* hold this position. -- Sent from Ubuntu signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Typos in 224-rend-spec-ng.txt
On Mon, Jul 21, 2014 at 9:00 AM, Tim t_e...@icloud.com wrote: https://trac.torproject.org/projects/tor/search?q=proposal+264 The search string is wrong, adjust to find this... https://trac.torproject.org/projects/tor/ticket/12424 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
