November 2013 - tor-dev - lists.torproject.org

recreated website png diagrams as svg
by Justin Findlay 13 Nov '13

13 Nov '13

Item h under https://www.torproject.org/getinvolved/volunteer.html.en#OtherCoding discusses (at least) the images at this page, https://www.torproject.org/about/overview.html.en which look as if they're copied from some EFF presentation. I've recreated them as svg. Svg being a fairly standard vector markup, I supposed that it would be more amenable to automatic string replacement than a png (I'm not sure what wml is). Please look them over and give me feedback. If they are ultimately found acceptable, you are welcome to use them for the site. Thanks. Justin

5 6

Finalizing translation strings
by Griffin Boyce 13 Nov '13

13 Nov '13

So I'm hiring translators for Cupcake, for Persian and Urdu translations. As it turns out, this is surprisingly inexpensive. Because I'm hiring translators anyway, I want to go ahead and donate translations of Tor project strings. (Especially Urdu, which is inexpensive, but difficult to find volunteers for). After looking at Transifex for a few projects, there seem to be some extraneous strings. Torbutton and TorBirdy both have a lot of single-character strings which don't make sense (or lack context). After chatting with Runa, decided to go ahead and post this to the list. If strings could be updated/finalized by early December, that would help the process a lot. =) best, Griffin -- Be kind, for everyone you meet is fighting a hard battle. PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97 OTR: saint(a)jabber.ccc.de

2 4

Notes on HS revamping
by George Kadianakis 11 Nov '13

11 Nov '13

Hey Nick, these are my notes from when I was writing the HS blog post. I updated them a bit with some more stuff. Might be helpful :) """ HS improvements: 1 performance 1.1 reuse IPs (#8239) 1.2 torperf (#8510) 1.3 scaling https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html 1.4 valet nodes 1.5 lasse's "Improving Efficiency and Simplicity of Tor circuit establishment and hidden services" 1.5.1 big design change. maybe worth it. assumes valet nodes IIRC 2 security 2.1 Crypto upgrade 2.1.1 Upgrade id keys [https://lists.torproject.org/pipermail/tor-dev/2013-October/005536.html] [https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html] 2.1.2 Upgrade IP service keys 2.1.3 Fix hybrid encryption (?) 2.2 Onion anti-harvesting (#8106) https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html 2.3 Guard node enumeration (#9001) 2.3.1 Virtual Circuits? Guard tiers? 2.4 Unpredictable HSDirs (#8244) 2.5 Hide HS popularity 2.5.1 Oblivious transfer for HSDirs (is it needed if we have #8106? maybe yes.) 2.5.2 Unlinkable introductions in IPs (is this even possible?) (do we even care? we have service keys) 3 Can we decrease the responsibility of guard nodes? It seems that security of HSes == their guard nodes, atm. 3.1 Implement stuff from https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… 3.2 Add optional padding/bitrate anti-fingerprinting transport for HSes. 3.2.1 Can be enabled by truly paranoid HSes. 3.2.2 But this is going to make HSes stand out even more! 3.2.3 These transports can all be broken anyway. Except a truly slow but theoretically secure padding/constant bitrate transport. 3.3 What are other anonymous publishing protocols doing here? I2P seems to be weak here too, according to Grothoff's recent paper. 4 misc 4.1 HSDirs system 4.1.1 Do we still need the hash ring even after #8106? 4.1.2 Look into Valet nodes 4.2 petnames/human memorable onions? 4.2.1 maybe better as a third party (probably unofficial) plugin to tor/firefox 4.3 Read and compare with other HS-like designs. See: 4.3.1 I2P, GNUNet, rewebber, retroshare, "Anonymizing censorship resistant systems" by Serjantov, ... 4.3.2 Check uni-directional tunnels of I2P and their pros/cons. 4.3.3 http://freehaven.net/anonbib/ 4.4 Encrypted servives https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en… 5 What else should we do? How would we design HSes if we were not prejudiced by the current design? """

4 7

[fwd] Re: [perpass] DNS confidentiality (from: bortzmeyer@nic.fr)
by Wendy Seltzer 11 Nov '13

11 Nov '13

I thought this might be of interest to the Tor community. --Wendy ----- Forwarded message from Stephane Bortzmeyer <bortzmeyer(a)nic.fr> ----- Date: Mon, 11 Nov 2013 13:10:27 +0100 From: Stephane Bortzmeyer <bortzmeyer(a)nic.fr> To: Stephen Farrell <stephen.farrell(a)cs.tcd.ie> Cc: perpass <perpass(a)ietf.org>, Andy Wilson <andrewgwilson(a)gmail.com> Subject: Re: [perpass] DNS confidentiality User-Agent: Mutt/1.5.21 (2010-09-15) On Wed, Sep 25, 2013 at 02:40:59PM +0200, Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote a message of 13 lines which said: > May be starting with the more modest but certainly useful "DNS > privacy considerations" Internet-Draft? Such a document, just > documenting the problem, would be a good idea, IMHO. Done. http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy _______________________________________________ perpass mailing list perpass(a)ietf.org https://www.ietf.org/mailman/listinfo/perpass ----- End forwarded message ----- -- -- Wendy Seltzer -- wseltzer(a)w3.org +1.617.715.4883 (office) Policy Counsel, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile)

1 0

Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF
by Jacob Appelbaum 10 Nov '13

10 Nov '13

hellekin: > On 11/09/2013 03:36 PM, Jacob Appelbaum wrote: >> >> I've given it an edit pass - I've included the original, a unified diff >> and my modified version. >> > *** Thank you! > > I will fix the formatting and a typo. Thanks! > > The rest looks good to me, except the references section. > > I think it would be better to have a "nice URL" that will stand the > proof of time: https://torproject.org/torspec would match the repository > name. Then either do some redirection magic to the latest version, or > better, list the various specs with an #anchor matching the name you use > in reference. I don't think we'll have anyone add such redirects any time soon, sadly. They're sorta ugly but they're accurate. All the best, Jacob

1 0

torbutton user agent update scheme idea
by Justin Findlay 09 Nov '13

09 Nov '13

Sorry for always picking random stuff from the volunteer page, but having read this, <quote> Programs like Torbutton aim to hide your browser's UserAgent string by replacing it with a uniform answer for every Tor user. That way the attacker can't splinter Tor's anonymity set by looking at that header. It tries to pick a string that is commonly used by non-Tor users too, so it doesn't stand out. Question one: how badly do we hurt ourselves by periodically updating the version of Firefox that Torbutton claims to be? If we update it too often, we splinter the anonymity sets ourselves. If we don't update it often enough, then all the Tor users stand out because they claim to be running a quite old version of Firefox. The answer here probably depends on the Firefox versions seen in the wild. Question two: periodically people ask us to cycle through N UserAgent strings rather than stick with one. Does this approach help, hurt, or not matter? Consider: cookies and recognizing Torbutton users by their rotating UserAgents; malicious websites who only attack certain browsers; and whether the answers to question one impact this answer. </quote> I think the best answer is simple, although a little more than trivial to implement. If you want to anonymize the user agent, you need to mimic the user agent changes made by normal users across the web, and I'm positing that in any statistically significant sample of web users, the behavior will be similar and simple enough on nearly all orders of magnitude available, i.e., normally distributed in any analytical dimension. Think about the natural evolution of a typical web user's user agent. What are the factors that will result in a change of user agent? 1) A user may have more than one browser that they use on the same computer, 2) they may use the web on more than one device (phone, tablet, laptop, desktop), 3) and typical, stochastic upgrade patterns. For (1) and (2) there is not much torbutton could do to coordinate reasonable obfuscation among multiple version, logical, space, and time separated instances without way more effort than would be profitable. In fact, (1) and (2) ought to naturally provide most if not all the anonymizing that can reasonably be accomplished from torbutton's perspective without any action at all on torbutton's part. For (3), though, there is something that could be done by torbutton. Some factors to consider in constructing a stochastic user agent updater are: - which browsers automatically upgrade themselves? - which browsers bother the user to upgrade? - what are the typical user response patterns towards browser upgrades? Remember, we're thinking about a single browser on a single system. If there are things going on for that user external to this (reinstall windows, upgrade ubuntu, get a new computer, etc.) those effects are already accounted for by (1) and (2). Some investigative questions/statements to lead an analysis on this could be something like: 'what is the distribution of browsers for human web users?' 'what is the distribution of systems and system versions for human web users?' 'what are the significant correlations on the cartesian product of these two dimensions?' 'how do the browser versions in this product space evolve through time?' ... '2/3 of firefox users are on windows and their upgrade habits follow a temporal distribution that is a spike followed by an exponential decay of order 2.3', '0.8 of the remaining firefox users are on linux and their update habits are dominated by package management systems', etc. Then, upon finding the most significant trends in browser update patterns, construct a mechanism for torbutton that mimics them on a per user basis: Once a user installs torbutton, it samples (selects) a browser from the distribution of browsers and then follows that browser's typical upgrade pattern. The problem with this idea, I guess, is that torbutton will have to phone home to find out when browser updates are adopted by users so that it can make its change at the expectation value or whatever. The goal being to distribute torbutton users according to the distribution of all web users among all user agents, you must first find out what that latter distribution is and how it is likely to evolve. This second part is not so bad as it seems because I'm guessing that some forward standard deviations of the expectation value in the temporal sense will occur late enough after the browser update that torbutton can push it out to most installed instances (it's not going to happen before, causality and all). Justin

1 0

Registering special-use domain names of peer-to-peer name systems with IETF
by Christian Grothoff 09 Nov '13

09 Nov '13

Dear all, Together with Matthias Wachs and Hellekin Wolf, I'm preparing an IESG approval request for the reservation of special-use domain names for P2P networks according to RFC 6761. The goal is to reserve .onion, .exit, .i2p, .gnu and .zkey (so that they don't become ordinary commercial TLDs at some point) and to at the same time document their use and how they should be processed for the broader community. I've attached the current draft which we plan to submit shortly (unless, of course, we receive insightful comments that require major revisions). As two of the five pTLDs involve Tor, we would be happy for feedback from the Tor developer community. Happy hacking! Christian

4 3

Request for comment: scheduler heuristics
by Andrea Shepard 09 Nov '13

09 Nov '13

As some of you may be aware, I've been working on new scheduler code for Tor recently. Currently, Tor calls channel_flush_some_cells() whenever a channel becomes able to accept more writes, or channel_write_*_cell() whenever a new cell arrives on a channel able to accept cells without other queued cells on circuits. Thus, we can only see one channel at a time when making scheduling decisions, and the existing circuitmux code is only concerned with providing an API for implementing prioritization of circuits attached to a particular channel. The new scheduler aims to remove this limitation. To do this, we have to get a global view of all possible choices we could make about which circuit to get a cell from next, so instead we keep lists of channels which can currently accept writes and which currently have cells available to send, and trigger the scheduler using event_active() whenever a channel meets both conditions. Then the scheduler runs from a libevent callback and loops over the list of channels in the intersection of both sets. At present it just invokes the existing circuitmux code, so the behavior differs little from the old code, but this provides a framework where we can potentially see multiple channels simultaneously to make scheduling decisions. Notice, though, that as described it will rarely actually see more than one pending channel - just looping over them all every time is too greedy. We want to put off making those choices long enough to see all our options, without delaying so long the channel send queues downstream of the scheduler loop start emptying and the delayed choice actually causes increased latency. At first, NickM and I had discussed this and he suggested a global high/low- water mark system parallel to the ones for each connection; I added code to the channel layer to allow lower layer implementations to provide queue size and overhead estimates in a generic way, so now the channel code has an up to date estimate of the total number of bytes queued to send on all channels in both lower-layer queues and channel_t queues. I believe this design should not be used, because making the flow rate on one channel affect the scheduling of others like that is a potential DoS. If an attacker controls one node, he can build a circuit through a target node to that node, and then send traffic down it, but force the node to drain it only very slowly, keeping the target's queue size always above a minimum level. If the low-water mark for the global queue is set higher than the high-water mark for each connection it can prevent this, but remains vulnerable to a similar attack using multiple channels to different nodes. The simplest proposed fixes involve modifying the queue size used to control the scheduler to age out old contributions from non-draining or slow-draining channels - replace the actual queue size with an effective queue size which drains linearly at a some fraction of the node's expect bandwidth, or drops off exponentially. These are straightforward to implement, but I'm unsure what the best option is, so comment is invited. -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

1 0

Re: [tor-dev] [tor-assistants] Please help me plan and run meetings in ways that you'll find most helpful
by matt＠pagan.io 08 Nov '13

08 Nov '13

> We've been doing regular meetings for little over a month now, and I'd > like to get some feedback and solicit suggestions, complaints, and > ways to make the meetings suck the least they can. Please let me know > what's working for you, what isn't working, and what should be better. > Thanks for setting up the development calendar. I expect that is going to help me keep better track of scheduled meetings. I only found out about the calendar on IRC yesterday when you mentioned it, Was there an email I missed where it was announced? Matt Pagan

3 2

[Draft Proposal] Scalable Hidden Services
by Matthew Finkel 07 Nov '13

07 Nov '13

Hi everyone, This is a proposal I wrote to implement scalable hidden services. It's by no means finished (there are some slight inconsistencies which I will be correcting later today or tomorrow) but I want to make it public in the meantime. I'm also working on some additional security measures that can be used, but those haven't been written yet. Many thanks to George for his initial feedback. I pushed this version to my public repo, and will continue to push updates there. In reality this is really 3.2 proposals, so the end result, if accepted, will look significantly different, but I'm indecisive at this point about which of the designs is least dangerous. Thanks, Matt

5 8