- tor-dev - lists.torproject.org

Guidelines and processes for ethical Tor research
by Aaron Johnson 02 Oct '15

02 Oct '15

Hello, Today at the Tor developers’ meeting, we had a discussion about how to help ensure that Tor research is done ethically. We developed a set of general guidelines for ethical Tor research, and we sketched out a process that researchers should follow if they want to do work on the live Tor network. The guidelines at present are: 1. Only collect data that is acceptable to publish. In the case of encrypted or secret-shared data, it can be acceptable to assume that the keys or some shares are not published. 2. Only collect as much data as is needed (i.e. data minimization). 3. Limit the granularity of the data. For example, "noise" (i.e. added data inaccuracies) should almost certainly be added. 4. Make an explicit description of benefits and risks, and argue that the benefits outweigh the risks. 5. Consider auxiliary data when assessing the risk of your research. For example, data from snooping exit traffic can be combined with entry traffic to deanonymize users. 6. Use a test network when at all possible. The process we discussed is fairly lightweight. It amounts to notifying a Tor Review Group (TRG) of your plans and using the TRG's feedback to develop a research plan that respects the guidelines. This notification can be private to the TRG only (although public notification is preferred). The TRG would consist of Tor developers and researchers. We are going to continue developing the guidelines and process through the wiki: <https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics>. Please send any comments. Best, Aaron

1 0

Blocking-resistance in I2P (Was Re: Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.)
by str4d 02 Oct '15

02 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Yawning Angel wrote: > [Folding in the 2nd reply] >> If you know some details of how I2P resists blocking, please add >> them to this wiki page: >> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports > >> > It doesn't do anything special. Yet (see below). There are several reason for I2P not being blocked as much as Tor: * Traffic - I2P is used by fewer "clients" (tens of thousands) than Tor (hundreds of thousands to millions). * Content - I2P doesn't provide easy access to clearnet resources like Tor does. * Easiness - non-bridged Tor uses TLS as its outside protocol, and can therefore be easily identified using standard TLS identifiers for firewalls. Identification of I2P traffic requires special-purpose identifiers (which do exist, but add to the maintenance burden of the firewall). Thus, blocking I2P currently provides less value-for-effort than blocking Tor. > > The old TCP based protocol (NTCP) is trivially identifiable. We have been (slowly) working on NTCP2, a replacement for NTCP, for nearly 2 years now. We have two different proposals on the table [0], and are also considering the benefits of the mutual-authentication variant of Ace [1,2]. Anyone here interested in protocol design is welcome to add to the discussion! > > Blocking the more modern UDP protocol (SSU) would require looking > for high-entropy UDP or doing statistical attacks IIRC. Active > probing is possible if they run a node that's part of the network > and obtain enough key material (But, I'd need to look at the > floodfill system again to figure out how many nodes for how long is > realistically required). Active probing of this kind essentially requires that the adversary enumerate the entire netDB, because geographical information cannot be used to index into the hash table. We estimate there to be about 750 floodfills at present, so it's not outside the realms of possibility. However, in practice it isn't really viable: * By default, routers in China (and several other countries, picked based on the Press Freedom Index [3]) start in hidden mode, meaning they don't publish their details in the netDB. So harvesting attacks will not pick any of those up, and therefore won't be useful for matching the source of UDP packets. * I2P routers actively measure the performance of their peers, and make routing decisions based on their measurements. If an adversary dropped UDP packets based on matching their destination to the harvested netDB, the router would simply use other routers that aren't being blocked. The most vulnerable point in the system is actually the reseed servers - - blanket blocks on them can prevent a router from finding any initial peers. However, if a router can connect to a reseed server, it has a good chance of being able to connect to the network (HTTPS with certificate pinning prevents snooping on or modifying what peers a router is given). Now that I think of it, the reseed system would be an ideal location to start introducing PTs into I2P. We have been thinking about how to leverage PTs in inter-node communication for several years, but reseeding over PTs would be much easier to implement and would provide noticeable benefits (making blanket bans much harder). str4d [0] http://zzz.i2p/topics/1577-ntcp2 [1] https://moderncrypto.org/mail-archive/curves/2014/000151.html [2] https://moderncrypto.org/mail-archive/curves/2014/000163.html [3] https://github.com/i2p/i2p.i2p/blob/master/router/java/src/net/i2p/route r/transport/BadCountries.java -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWDc+cAAoJEBO17ljAn7Pgoq8P/iI2+qr6b65dYPpGCk8R2XA4 Dq2PxpjGX6n74PW96DWg7eHGGjCPLh22SnGSDoU7l6mDCAM9u7BTh1j/se5uMzuh 6Y2z3dml5L+I+JXd+WdqGQK8gFkAMXrVMc9waEY8bKC1/ENssUXBlN1Jfm3lcttj BirJxyc7c14EX2gHsMLE/cbgeVUl+sf4/A2cXqjLmlnrUSiGRBPx7AAU/fPbSA0P JgvYvbUQ0NCly8BSZkQRL5qh01DuF9ZD39JkOAvy+N0pW0EoCPjLVGsdY4RjWnSZ zQF2IJoig35gi6Tqxk/jUS1b6+hoCacTN7Ly00WAykAjJqFF5OfIaD60HJizdlbX 5aAwncAJhaddaMVpekp4zBhjI07gvZW9k3Nzjy6yRcBGYxg96PU5fedk37HTMcyu Ixpi2hu84FHDwE8YVfTVw9yrDzkp0azVsgS0CwJSONtrpfKDcU3z9L928N/abdMS d7OBJo3omPfMmjMyGjqjQ0+348oTVarEV4hfqDIICbvIPfXRWkGKRMcNEXbjcg+f +5gISZpZ+FX9UiyhWm4MP+B+fcyvT/QO5/wH0B1k9rBYO+1VUAFNKkzqBxqOy1QM 166irImK9kh5OTtdxww7guYx+h5zLOJSB3tcnEG5Ksu3rCY7iEnVV2C6bb8Irpg1 ItGd4ak9UDVtFN2HY0OX =oTAv -----END PGP SIGNATURE-----

1 0

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, thank you very much for your help. I really appreciate it. Below is the URL of the webpage which contains the technical documentation of I2P.* *https://geti2p.net/en/docs <https://geti2p.net/en/docs>* *The weak point of I2P is that the speed is slow.* *The strong point of Tor is that the speed is fast.* *If we can combine the strong point of I2P with the strong point of Tor, China's firewall would exist in name only.*

1 0

Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall. When will SkypeMorph Pluggable Transports and Dust Pluggable Transports be deployed in Tor Browser? There are no directory servers in I2P network. Can Tor learn from I2P? If Tor user have to access directory servers by bridges, I feel that Tor will be easily blocked by China's firewall. Can Tor no longer use directory servers in future? Since 2010 China's firewall has blocked all of the IP addresses of Tor directory servers. Thank you very much for your help. I really appreciate it. All the best with your work. Good luck in all that you will achieve.*

3 2

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, thank you very much for your help. I really appreciate it. In this afternoon of China Time, I found a obfs4 bridge which is usable in China. The speed of Tor Browser connecting with obfs4 bridge, and the speed of Tor Browser connecting with Meek Azure, which is faster? It is more difficult for China's firewall to block I2P. If Tor can learn some strong points of I2P in future, Tor can work better in China. Thank you very much for your help. I really appreciate it. All the best with your work. Good luck in all that you will achieve.*

2 1

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, thank you very much for your help. I really appreciate it. I don't know how long I can use the obfs4 bridge which I found. Maybe after two weeks the obfs4 bridge which I found would be blocked by China's firewall.*

1 0

Re: [tor-dev] Onion Services and NAT Punching
by Nathan Freitas 01 Oct '15

01 Oct '15

On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote: > On Wed, 30 Sep 2015 17:12:53 +0000, Tim Wilson-Brown - teor wrote: > ... > > Are there any use cases that: > > * need NAT punching, > > * don???t need service location anonymity, and > > * would benefit from lower latency? > > Of course. All the cases where you set up a hidden service > exactly because your host is behing a NAT. > > Like the webcam raspi I'm just booting up. I have been looking at the use of Tor and Onion Services for Internet of (Onion'd) Things applications, but broadly I haven't thought how and when single onions could add extra benefit. Mostly in IoOT (IoO?) the goal is to remove the centralized corporate clouds that are currently used, and to protect your endpoints (house, car, office, etc) from becoming easily discovered and compromised. Accessing a home webcam ("dropcam" or "baby monitor" in the common parlance) is the best example I can think of where you want all the Tor goodness, and lower latency is also needed. Most of the other apps I can think of can deal with async messaging and high latency (i.e. change/check your thermostat settings). +n

1 0

Expanding services: Single-onion and OnioNS
by Hugo Maxwell Connery 01 Oct '15

01 Oct '15

Hi, Having reviewed the last couple of months of tor-dev mails, i can see that there are many proposals afoot to expand the uptake of tor hosted services. These range from a new service type, single-onion [0], to load balancing of tor hosted services [1], to hosting new name/value pairs (x-namespace) [2], to new name services (OnioNS [3] and better integration of Gnu NS [4]), to name a few that caught my eye. The fact that Facebook (which I wholely dislike) expended considerable effort in generating a human readable location hidden service address and then strongly participated in IETF discussions to declare .onion as a special case TLD reservation indicates that the perception of the validity and significance of the tor network is growing. I have comment on single-onion services and on name services. For single onion services, in which client -> guard -> middle -> middle -> single-onion, the role of the second middle relay changes. In the traditional sense it merely knows that it is part of a circuit connecting two relays, and has no knowledge at all about either source (client) or destination (normal web service). For single onion services the second middle relay can know something about the service to which it is connecting. As Yawning Angel points out [5] this may provide censorship opportunities. For this, I suspect that single onion service operators need to be made aware of this risk. If they are aware, they can persue strategies to mitigate (e.g run multiple contact points over a back end). John Brooks identifies [6] a potential risk for the second middle relay operator if the single onion service is malicious (keeps detailed logs, runs a honeypot etc.). For this case, and to help peole who provide large capacity middle relays (e.g Mozilla) and wish for no legal risk, a config flag may need to be provided which allows middle relays to choose not to connect to single onion services. There may be other, better strategies. I wish also to highlight the potential importance of Jesse V's OnioNS [7]. I am highly supportive of alternatives to the DNS, which despite efforts ongoing in the IETF, will never be secure against surveillance. OnioNS attempts to solve Zooko's triangle. It seems a well considered name system, and I encourage others to examine it. The key benefits are that a service can choose a name for itself, but must do work to do so, and must regularly do work to maintain the name (thus costing squatters effort). The name service operates entirely within the location hidden services space and thus offers the protections inherent in that. Registration is at the second level (e.g example.tor) but can also at the same time register lower levels names (e.g xmpp.example.tor and gopher.example.tor). Regards, Hugo [0] https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html [1] https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html [2] https://lists.torproject.org/pipermail/tor-dev/2015-September/009588.html [3] https://lists.torproject.org/pipermail/tor-dev/2015-September/009585.html [4] https://lists.torproject.org/pipermail/tor-dev/2015-September/009560.html [5] https://lists.torproject.org/pipermail/tor-dev/2015-September/009416.html [6] https://lists.torproject.org/pipermail/tor-dev/2015-September/009415.html [7] https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conferen…

1 0

Re: [tor-dev] Second release of OnioNS beta
by Jesse V 01 Oct '15

01 Oct '15

Heads-up everyone, After some debugging with s7r, it appears that sometimes the programs (onions-server, onions-hs, or onions-client) fail to start because they cannot load the common library. So if you run any of the programs in the terminal, you will see an error that libonions-common.so cannot be found, or they simply won't run if you start them without an active terminal. This is because that library is installed to /usr/lib/onions-common, but the loader is looking for it in /usr/lib/, among other locations. I do set the RPATH in CMake in an attempt to fix this, but in some cases (at least in my build for Debian Wheezy) it may not be set or installed correctly. I'm investigating and looking through https://cmake.org/Wiki/CMake_RPATH_handling If this occurs, there are two workarounds. The first is to run export LD_LIBRARY_PATH="/usr/lib/onions-common" before running any of the software. The second is to add "/usr/lib/onions-common/" (without quotes) to /etc/ld.so.conf Both should tell the loader to look for the library in the correct path. This issue might also occur on Fedora under the for the experimental .rpm, but I'm not sure. The issue doesn't occur on my computer, but if it also applies to Ubuntu or Mint, please let me know. It's always possible to compile from source and run the software from the build directory, but I would really like to identify the scope of this issue and then properly fix it. Thanks, Jesse V.

1 1

Draft proposal -- no number yet: How to safely drop support for old clients.
by Nick Mathewson 30 Sep '15

30 Sep '15

[This isn't done yet, but I've shown it to enough people that I should share it with the list.] 1. Introduction and background 1.1. Motivation Frequently, we find that very old versions of Tor should no longer be supported on the network. To remove relays is easy enough: we simply update the directory authorities to stop listing them. But to disable clients is harder. We can do as we did with v1 directories in Tor 0.2.0.5-alpha, and make them know about no relays at all. Stepping back -- why should we disable very old clients at all? Here are some reasons why: * Security. Anybody who hasn't updated their Tor client in 5 years is probably vulnerable to who-knows-what attacks. They aren't likely to get anonymity either. * Withstand zombie installations. Some Tors out there were once configured to start-on-boot on now-unmaintained systems. They put needless load on the network, and can't be easily disposed of. * Disable backward-compatibility code. Currently, Tor supports some truly ancient protocols in order to avoid breaking ancient versions. If we disable these protocols without turning off the clients that use them, we run the risk that those clients will run wild, retrying their connections to the network over and over. This document describes a designs for use with future versions of Tor to better support client deprecation and removal. It also describes how we can safely disable existing client versions that do not support this proposal. 1.2. History Early versions of Tor checked the recommended-versions field in the directory to see whether they should keep running. If they didn't recognize 1.3. Goals and requirements We need older clients to stop putting (much) load on the network. Having them stop working entirely is not sufficient: they need to stop working in such a way that they don't keep using up resources. In the future, when we disable a client, it would be a good thing to provide some means to warn users in advance that they need to upgrade, and to provide advice about doing so. It might be good to make any disable-switches advisory rather than mandatory. 2. Adding a disable-clients switch to consensus documents I specify a new consensus element: disable-versions. It may appear any number of times in a consensus document. The syntax is: disable-versions SP SOFTWARE SP ROLE SP DATE SP VERSIONS DATE = A date in YYYY-MM-DD format ROLE = "relay", or "all". SOFTWARE = "Tor" VERSIONS = VERSION_RANGE VERSIONS = VERSIONS SP VERSION_RANGE VERSION_RANGE = VERSION VERSION_RANGE = VERSION..VERSION [TODO: Specify voting.] If the current version is listed in any disabled-versions line for its current role, then we should warn the user. If the current date is on after the date specified (starting midnight UTC), we should disable the host as follows: * If 'relay' is the disabled role, then we should enter ClientOnly mode. * If 'all' is the disabled role, we should enter DisableNetwork mode. Note that the DisableNetwork behavior means that once a client is disabled, it will not fetch new consensuses. To override this, a Tor instance may include a configuration option, "IgnoreDisabledVersion VERSION". It is an error to set this option when *not* running with a disabled version. [ALTERNATIVE: Make RequireLinkProtocol, RequireCircuitProtocol, etc lines for the consensus. Any Tor not supporting those protocols should behave as above. This allows non-Tor implementations to respect these fields.] 3. Disabling current client versions. 3.1. Disabling versions that use the v2 handshake These versions (before 0.2.3.6-alpha) use a renegotiation-based handshake instead of our current handshake. When we detect a renegotiation attempt, we can close the connection, or stop reading on it. 3.2. Disabling versions prior to 0.2.4.11-alpha. Starting in version Tor 0.2.4.11-alpha, we implemented proposal 214. This proposal added a new link protocol, version 4. Earlier version of Tor never support it; newer versions of Tor always advertise their support for it. We could treat the presence of any link protocol of version 4 or later as indicating the presence of 0.2.4.11-alpha. Upon receiving a connection from such a version, we could throttle the bytes we give it, drop its circuits, or stop reading. [TODO: which?] 3.3. Disabling versions prior to 0.2.5.x In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option, and always preferring the ntor handshake where available. Unfortunately, we can't simply drop all TAP handshakes, since clients and relays can still use them in the hidden service protocol. But we could detect these versions by: Looking for use of a TAP handshake from an IP not associated with with any known relay, or on a connection where the client did not authenticate. (This could be from a bridge, but clients don't build circuits that go to an IntroPoint or RendPoint directly after a bridge.) In response, we can throttle the connection, drop all its circuits, or stop reading on it. [TODO: which?] 3.4. Disabling all versions that don't support this proposal We should allow 'n' (short for "node") as a synonym for 'r' in consensus documents. Later, if we want to disable all Tor versions before today, we can change the consensus algorithm so that the consensus (or perhaps only the microdesc consensus) is spelled with 'n' lines instead of 'r' lines. This will create a consensus which older clients and relays parse as having no nodes. 3.5. In the event of overzealous retries We need to be sure that client running versions from 0.2.1 through 0.2.6 respond gracefully to the responses above. In particular, we need to make sure that they don't continually retry the connections that fail in these ways: that would put a lot of extra load on the network. Above, I recommend stalling connections rather than just closing them. This may prevent the risk of retries, at the risk of using additional relay resources. To handle something like this, it could be necessary to use the trick of 3.4 above.

4 3

Anycast Exits (related : Special-use-TLD support)
by Jeff Burdges 30 Sep '15

30 Sep '15

I have attached below the second half of the Special-Use TLD proposal that discusses how a local name service tool contact a peer-to-peer application running on an exist node There is nothing specific here to providing name services, any peer-to -peer application might potentially want an anycast style gateway from Tor to its own network. At the same time, this proposal is *very* hackish since Tor seems almost able to provide the same functionality with a judiciously chosen ExitPolicy lines, and a bunch of work on the application's side. And maybe that's really the right way to do it in the end. There is no discussion here of dealing with bad exit gateways for protocols that Tor does not even know about, presumably that requires some thought as well. I donno if Tor combats exits doing highly targeted DNS manipulation all that well either though. Jeff Filename: xxx-anycast-exit.txt Title: Anycast Exit Author: Jeffrey Burdges Created: 28 September 2015 Status: ? Implemented-In: ? Abstract Provide an anycast operation to help bootstrap Tor aware peer-to-peer applications. Overview Peer-to-peer protocols must define a method by which new peers locate the existing swarm, but available techniques remain rather messy. We propose that Tor provide an "anycast" facility by which peer-to -peer applications built on top of Tor can easily find their peers using the full aka useless descriptors. Server Side We propose an AnycastExit Tor configuration option AnycastExit <protocol> <host>:<port> Here protocol must be a string consisting of letters, numbers, and underscores. There are two changes Tor's behavior resulting from this option : First, Tor adds the line "ACE <protocol> <host>:<port>" to the node's full descriptor. Second, Tor allows connections to ip:port as if the torrc contains : ExitPolicy allow<host>:<port> As ExitPolicyRejectPrivate defaults to 1, these policies should be allowed even if the ip lies in a range usually restricted. In particular localhost and 127.0.0.1 are potentially allowed. Client Side Users enable anycast usage by adding the configuration line FetchUselessDescriptors 1 Software queries the Anycast lines in the full descriptor by sending Tor control port the line : GETINFO anycast/<protocol>/<number> This query returns 250-anycast/<protocol>/<number>="<host>.<identity>.exit:<port>" where <identity> is a node identity for a node whose full descriptor contains the line "Anycast <protocol> <host>:<port>". After receiving such a query for anycast nodes supporting <protocol>, Tor builds, and later maintains, a list of nodes whose full descriptor contains an "ACE <protocol> .." line in lexicographic order according to <identity>. Tor returns the <number>th node from this list. Also, if <number> exceeds the number of nodes with Anycast <protocol> lines, then an error is returned. Clients contact the anycast server <host>.<identity>.exit on port <port>. As AllowDotExit defaults to off, applications should use the Tor control port to request a circuit to that particular exit using MapAddress: MapAddress <host>.<identity>.exit=<label> After this, the peer-to-peer application can connect to <label> over the Tor socks port. MapAddress usually produces a four hop circuit, but many peer-to-peer applications, including name service provides, can accept the small additional latency. Future Work Tor directory authorities could aggregate the lists of anycast supporting nodes, so that clients do not need to download the full descriptors. AnycastExit could support UNIX domain sockets. Hackish Alternative In principle, the ExitPolicy line produced by AnycastExit might suffice if both doing so bypasses ExitPolicyRejectPrivate, and the port could identify the protocol. Additionally, an application could parse the cached-descriptors* files themselves to locate exits with the desired exit policies. Acknowledgments Based on discussions with George Kadianakis, Christian Grothoff. Indirectly based on discussions between Christian Grothoff and Jacob Appelbaum about accessing the GNU Name System over Tor.

2 2

Rate limiting of a hidden service
by Evan d'Entremont 30 Sep '15

30 Sep '15

I developed a scheme to rate limit hidden services using proof-of-work; https://gist.github.com/evandentremont/a3ad12a5cc3a924dae34 The server sends a semi-prime to the client, which then factors it. The client submits the factored primes back with the next request. The 'rate' can be throttled by sending a larger or smaller semiprime. The client has to spend time factoring that number, and the request can simply be dropped if the factored primes aren't correct. It would be effective to hinder brute force attacks on a login screen at the very least. Running as a script on the page isn't ideal as a lot of people disable javascript. There's always the option for a fallback where you calculate the primes yourself and submit them, but I feel like it would be better implemented as part of tor itself. Just throwing this out there for thoughts / feedback / opinions on rate-limiting hidden services.

1 0

Approaching Deadline: ICGCTI2015 - Malaysia
by Jackie Blanco 30 Sep '15

30 Sep '15

The Third International Conference on Green Computing, Technology and Innovation (ICGCTI2015) Universiti Putra Malaysia, Selangor, Malaysia 8-10 December 2015 http://sdiwc.net/conferences/icgcti2015/ The proposed conference on the above theme will held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICGCTI2015 aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Benefits of, and barriers to, adopting greener IT practices - Carbon metering and user feedback - Climate and ecosystem monitoring - Energy harvesting, storage, and recycling - Energy-aware high performance computing and applications - Energy-aware software - Energy-efficient network services and operations - Green IT metrics, maturity models, standards, and regulations - Green computing models, methodologies and paradigms - Green networking and communication - Life-cycle analysis of IT equipment - Management and profiling tools for energy efficient systems - Modeling-representations, simulation and validation for energy consumption optimization problems - Online dynamic optimization for energy efficient systems - Power-aware algorithms and protocols - Power-efficient delivery and cooling - Renewable energy models and prediction - Smart buildings and urban development - Smart homes, buildings, offices, streets - Stability of smart energy systems - Using IT to reduce carbon emissions - Carbon management policies and ecology- related issues with ICT - Characterization, metrics, and modeling - Creating green awareness using IT - Energy-aware computing - Energy-aware large scale distributed systems, such as Grids, Clouds and service computing - Energy-efficient mass data storage and processing - Governments’ roles in fostering and enforcing green initiatives - Green business process reengineering and management - Green design, manufacture, use, disposal, and recycling of computers and communication systems - Green software engineering - Low-power electronics and systems - Matching energy supply and demand - Network design optimization - Optimization of energy-efficient protocols - Power-aware software and hardware - Reliability, thermal behavior and control - Robustness and performance guarantees - Smart grid and microgrids - Smart transportation and manufacturing - Sustainable computing Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Deadline : November 8, 2015 Final Notification : November 20, 2015 Camera Ready Deadline : November 28, 2015 Registration Deadline : November 28, 2015 Conference Dates : December 8-10, 2015 Drop us an email at icgcti15(a)sdiwc.net

1 0

Second release of OnioNS beta
by Jesse V 30 Sep '15

30 Sep '15

Hello everyone, I am pleased to announce the second release of the Onion Name System (OnioNS) for beta testing. This release represents about 180 commits and is a major update from my last release. The two servers should be up long-term, so feel free to play around with it. "Example.tor" is live and new registrations should be available client-side about 20 seconds after upload. As usual, the code, pre-built binaries, and instructions are available in the four OnioNS repositories at https://github.com/Jesse-V?tab=repositories Please star them if they work well for you. Most people will probably just want OnioNS-client, which integrates into the Tor Browser. The big changes include: * Servers are now powered by hidden services. This means that they utilize existing Tor connections (circuits and TLS links) which is a major improvement over the direct communication in the last release. In the process, I switched all communications from SOCKS4 to SOCKS5 and it seems to work well. The OnioNS servers would be excellent candidates for single-onion services (Tor-embedded servers with only client-side anonymity) so I will switch to that when they becomes available. * Servers now manage Ed25519 keys and I'm using floodberry's ed25519-donna implementation. All responses from a server are signed, so communication is automatically authenticated. The private key is held in the main working directory, which is ~/.OnioNS/ for the time being. Due to this, it's not currently possible to run two distinct servers as the same user. * The trusted Quorum server now generates a Merkle tree and signs the root, which the client uses to authenticate Records (registrations) and to provide authenticated denial-of-existence. In effect, this prevents the client's name server from falsely returning a 404 or from forging a Record. * I overhauled most of the networking code. It's significantly more stable, closely follows a request-response pattern, and I don't anticipate needing to change the networking format in the near future. * The hidden service software now saves the generated Record to disk, so that it can try again if the upload fails. * I introduced two static analysis tools: cppcheck and Clang's scan-build and created the scanBuild.sh script to facilitate analysis. They found one small memory leak, which I fixed, so now all of the repositories pass inspection. * I'm now using the Travis continual integration system, which watches for commits in Github and then rebuilds the project. I get notifications in #tor-bots if the repo fails to build into a .deb, which is handy. Any pull requests are also checked in the same way. * Many bugs were identified and fixed. I need some help with: * Testing a linking bug that is sometimes encountered when compiling from source. The ticket is https://github.com/Jesse-V/OnioNS-server/issues/79 I don't know whether the issue is dependent on Debian Wheezy, Ubuntu Trusty, or my CMakeLists. I'm not sure how to fix it, either. * Testing an experimental .rpm format. I used the "alien" program to convert Wheezy and Trusty .deb files to .rpm, so as to better cater to Fedora. The rpm's are available in the Releases page on Github. I don't know if the packages work correctly, so if you are on Fedora, please try them out and let me know. If they don't work, I would appreciate instructions on how to build them properly. * General testing: does the HS-side and client-side code work well and perform reliable for you? Related notes: * Earlier this month someone in Egypt created the ".tor" article on Wikipedia, which has a few details about this project. Thanks for that! * S7r, I couldn't contact you on IRC, but if you're still up for running a name server to handle client connections, please let me know. I'll need your HS address and your server's Ed25519 public key, which is shown when the server starts. Then I'll push out an update that should transition clients over to you. It'll be nice to spread out ownership of the infrastructure. Next on the list: * I'm planning to focus the next release on stability, security, unit tests (I'm looking into coveralls.io), and doxygen documentation. The code is currently a bit fragile, so I'd like the next release to improve error handling. I'll be maintaining this version until the next one comes out, so I made a "stable" branch which will be for bug fixes and the like. I recommend that Ubuntu/Mint users use the PPA so that it's easy to deploy updates. * I need to let servers update themselves if they are out-of-date. Once I fix this, it should be straightforward to add more servers to this system. Thanks for the support everyone, and enjoy testing! Jesse V.

1 0

Proposal: Merging Hidden Service Directories and Introduction Points
by John Brooks 29 Sep '15

29 Sep '15

Hello! George and I, along with the other participants of this hidden services meeting, have written a proposal for the idea to merge hidden service directories and introduction points into the same entity along with proposal 224. Comments are encouraged, especially if there are downsides or side effects that we haven’t written about yet, or that you have a different opinion on. The intent is that we can decide to do this before implementing proposal 224, so they can be implemented together. The proposal is attached, and also available from: https://raw.githubusercontent.com/special/torspec/224-no-hsdir/proposals/id… Thanks! - John

11 19

Re: [tor-dev] Special-use-TLD support
by str4d 29 Sep '15

29 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Jeff Burdges wrote: > Very interesting. Yes, this sounds reasonable in the short run. In > the longer run, there are several people with an interest in > externalizing Tor's DNS handling, which changes things. I'll > check out OnioNS and discuss this with people at the meeting. > Thanks for making this proposal! I am very interested in seeing it become a more general-purpose method for externalizing DNS handling. I2P has supported pluggable NamingServices for a long time, and it is trivial to add new methods. Now that Tor is considering them, I would like to see whatever protocol is decided on standardized in some way, so that GNS, Namecoin etc. can implement one protocol and be interoperable with both Tor and I2P. I include some comments below to this effect. I would expect that if this went ahead, this spec would be split into a) a general spec for the RPC protocol, and b) how Tor itself uses the protocol. > > > Filename: xxx-special-use-tld-support.txt Title: Special-Use TLD > Support Author: Jeffrey Burdges Created: ?? Sept 2015 Status: Draft > Implemented-In: ? > > Abstract > > Suppose Special-Use TLDs in Tor via external Domain Name System > (DNS) suppliers, such as the GNU Name System and Namecoin. > > Background > > Special-use TLD supplier software integrates with the host > operating system's DNS layer so that other software resolves the > special-use TLD identically to standard DNS TLDs. On Linux for > example, a Special -Use TLD package could create a plugin for the > Name Service Switch (NSS) subsystem of the GNU C Library. > > Tor cannot safely use the local system's own DNS for name > resolution, as doing so risks deanonmizing a user through their > DNS queries. Instead Tor does DNS resolution at a circuit's exit > relay. It follows that Tor users cannot currently use special-use > TLDs packages in a safe manor. > > In addition, there are projects to add public key material to DNS, > like TLSA records and DNSSEC, that necessarily go beyond NSS. > > Design > > We denote by N an abstract name service supplier package. There > are two steps required to integrate N safely with Tor : > > Of course, N must be modified so as to (a) employ Tor for its own > traffic and (b) to use Tor in a safe way. We deem this step > outside the scope of the present document since it concerns > modifications to N that depend upon N's design. We caution > however that peer-to-peer technologies are famous for sharing > unwanted information and producing excessively distinctive traffic > profiles, making (b) problematic. Another proposal seeks to > provide rudimentary tools to assist with (a). This "must" would need to be generalized to "employ anonymizing services for its own traffic" if left in the general spec. In practice this will probably just be Tor if exit nodes are the means for communicating with clearnet N nodes, but the spec shouldn't be restrictive in this regard (e.g. N nodes run from Tor HSs or inside I2P) . > > We shall instead focus on modifying Tor to route some-but-not-all > DNS queries to N. For this, we propose a NameService configuration > option that tells Tor where to obtain the DNS record lying under > some specific TLD. > > Anytime Tor resolves a DNS name ending in an Special-Use TLD > appearing in an NameService configuration line then Tor makes an > RPC request for the name record using given UNIX domain socket or > address and port. > > We should allow CNAME records to refer to .onion domains, and to > regular DNS names, but care must be taken in handling CNAME records > that refer to Special-Use TLDs handled by NameService lines. Tor > should reject CNAME records that refer to .exit domains. > > Configuration > > We propose two Tor configuration options : > > NameService [.]<dnspath> <socketspec> [noncannonical] [timeout=num] > [-- service specific options] > > We require that <socketspec> be either the path to a UNIX domain > socket or an address of the form IP:port. We also require that > each <dnspath> be a string conforming to RFC 952 and RFC 1123 sec. > 2.1. In other words, a dnsspec consists of a series of labels > separated by periods . with each label of up to 63 characters > consisting of the letters a-z in a case insensitive manor, the > digits 0-9, and the hyphen -, but hyphens may not appear at the > beginning or end of labels. > > NameService rules route matching queries to appropriate name > service supplier software. If a trailing substring of a query > matches <dnspath> then a query is sent to the <socketspec> using > the RPC protocol described below. NameService rules are applied > only after all MapAddress rules. > > There is no way to know in advance if N handles caching itself, > much less if it handles caching in a way suitable for Tor. > Ideally, we should demands that N return an appropriate expiration > time, which Tor can respect without harming safety or > performance. If this proves problematic, then configuration > options could be added to adjust Tor's caching behavior. > > Seconds is the unit for the timeout option, which defaults to 60 > and applies only to the name service supplier lookup. Tor DNS > queries, or attempts to contact .onion addresses, that result from > CNAME records should be given the full timeout allotted to > standard Tor DNS queries, .onion lookups, etc. > > Any text following -- is passed verbatim to the name service > supplier as service specific options, according to the RPC > protocol described below. > > Control Protocol > > An equivalent of NameService should be added to the Tor control > protocol, so that multiple users using the same Tor daemon can > have different name resolution rules. > > RPC protocol > > We require an RPC format that communicates two values, first any > service specific options give on the NameService line, and second > the query name itself of course. We might however discuss if there > are any standardized flags, distinct from these options, and > whether they should be communicated separately. > > In principle, Tor could make due with simply receiving a strong in > "strong" -> "string" > return. We recommend however that Tor expect a return format as > or more powerful than full DNS queries. In particular, we should > endever to return TLSA records at the same time as the underlying > DNS record, so that Tor Browser can utilize that key material. > The GNS Record format used by the GNU Name System addresses this > and other issues, so it should be taken as a candidate. See : > https://github.com/GNUnet/gnunet/blob/gnunet/src/include/gnunet_gns > > > record_lib.h For host names that the external service maps to I2P servers, I2P would ideally like the record to contain the full Destination, because then only one lookup is required. This is not a domain name-like value, like foo.onion or bar.b32.i2p, so the ability for the returned record to support these kinds of return values should be considered. If a domain name-like value is required, then I2P would need to do two lookups - one for spam.gnu -> bar.b32.i2p, and then a second (internal) for bar.b32.i2p -> DESTINATION. This partly also depends on what kind of records the external service supports, but IMHO the RPC protocol should not be limiting in this regard, given that it will likely only be used by networks like Tor and I2P that cater to more than IPv4 and IPv6. > > Sepcial-use tLD suppliers should internally process CNAME records "Sepcial" -> "Special" > that fall into their own domains, but they should return CNAME > records to Tor that refer to .onion or .exit domains, or to normal > DNS names. Initially, Tor should issue an error if it receives a > CNAME record that matches an NameService line. If however that > NameService line contains the noncannonical option, then CNAME > records should instead bypass it, and use Tor's DNS system. It's not clear to me a) where this is useful for Tor, and b) where this is useful in general. Can you provide an example? > > At present, alternative DNS packages should not pass CNAME records > between themselves, despite speaking the same RPC protocol, as > this creates unknown risks. As such forwarding can be done most > safely by Tor itself, the Tor Project reserves the right to > forward CNAME records between NameService lines in the future. > Applications should therefore not depend upon the above error > being returned. One thing that the I2P NamingService impl doesn't do is recursive lookups, because we haven't had a need for them yet (we instead have an optional fallback system where if a lookup fails with one configured service, it can try another one). But it wouldn't be hard to implement, and I agree with having the RPC user handle CNAME records instead of the external service. str4d > > Variations > > Tor would conceivably benefit from externalizing its own DNS > handling as a separate process. This might however require that > Tor have the ability to start name service suppliers. A fuller > consideration of this might alter our design of the NameService > configuration option. > > Acknowledgments > > Based on extensive discussions with Christian Grothoff and George > Kadianakis. > > > > > > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWCfHfAAoJEBO17ljAn7Pg5xsP/A+6JT4/ZZ0ZIBJ3YTPefAd7 D42WCHDKc8F5u2SC3NzqlryvfmXN6INlEDHx7JzGg2j52AdjhXbzpR58U6rZS1LE El/mzh3ZnIV8PpzfojY+SU7eQ/4cAgr8hJW3/x8rIRBlt2ZRBpWyKYPKBDtZtOzp ptbNs7rjio28ymaPEpdyT7by9SzE6GiC4k4LGJnDxMUhk/f2EzjwpQJ7Um4pkKmV ziV1FpUcuWbnXlz4rVs08DO/aULQs6d7He494XoA06HgFnTqXRirg3DdsxffbDDR 7UkL5DzM1IXb0yv2VXyB3DfUI4L5w5kZoDtaGsYtUoIZdtHJlrcV96eodAjp1PTJ PpubSRZc/pC0tL5ol9FyGkDg/Gh+HWSHyVYkY+RJo7/4pSJc6lt/ruUQNvpRqYty BpW8YtVHURRoThjkJ5SAWjXC96ET0yLpAXo3O9aFeNQt36vG33GmqdNHzA6x2vb8 yHjB7YlxtDsoj+o+O9cJ/9vPLKeeMjOhd6xFQaujFIOCxFT374R3WMUyniIEmrPv dI86kalXyDM8HZ80Q4QVqDZkEZKSWdigp149cTMhU279CpmsIVPjAXWucXChtT6E +u2MSFsGSN6mRZEGosJty18HBgS218IvYUI1IQbYfGM3mD6gL0+SEq8hNT/Bj500 r8yIwBccfe1IXEXdxyn7 =X7ur -----END PGP SIGNATURE-----

1 0

Interruption in patch workshop and (online) tor dev meeting this week
by Nick Mathewson 28 Sep '15

28 Sep '15

Hi, all! I hope things are going well for you. This week, many tor developers are all at a meeting in Berlin. So, there will probably be far fewer people than usual at the Tuesday patch workshop time or at the Wednesday tor status meeting. We should be back as usual next week! peace, -- Nick

1 0

Reminder for weekly OONI dev meeting Monday 2015-09-28 17:00 UTC (19:00 CET)
by Vasilis 28 Sep '15

28 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, This is a reminder that today there will be the weekly OONI meeting. It will happen as usual on the #ooni channel on irc.oftc.net at 17:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). Everybody is welcome to join us and bring their questions and feedback. See you later, ~ Vasilis -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWCVPXAAoJEF+/cLHRJgFiyfEP/3MXP6nHjk9Q9ixRS+FOyKgt qqyeDWdrgrO5wrtoz3cuaeKqwmvACPAJdlXJUNhVOtwM7msziNZug9g7wWi/W7Tv 0LJZ0+YTRyQ9RPGV+ldAM+n0ZELywP6l3trh9Yoa9Q/wgOwhrulVpsuxtgh2DkfJ KZXGI5dR1io+N90/9f5lk0Ed45P1w4JWMw4qtOGJ+5YA0W3Du0R25shgkfglZJpt Wx9hZilingxqrbtqczc8JFet8QFmkZifrO/+SkX8iTCYGTxhRihsLjlE4yxZd5hS k0PNeFlfB13x3tgESwY4prIe1oTch5qVWAgGDcMeSgnK/2Om8xiwdWMufTuHHgE/ 2GkbQ0pRNNn8a1B+MnVOelVktC7Cv8znAP9Aq6V7bwLSRKaBIYBjKyAd+5NmpuGl UxGPeUvSPSyIDlnPV68tfHtNrj65HuZ2mcs7a8dWmD6ODboETxTXkf5aDAMG2sly wQ6GuNCZKCJa0bHhQE9ADk7QnR8LUDRbzi4hJ9TSQrFmi1hlJhHZGDxO3ihw2nGe qz0PBkagbb6RIMHbXy6GObezIf9l14N+CUiCsg93CKKZaPpjgyqR2kkCsSX/Vi9r eN9CjxPP6rbQ/8H0T5MQy2V6Oq8YAoEGOGTUpOnwfnONk4Za39nKwwuk5JeGSTyr NL6UnDm/bhvSd24Sp4Vv =xZmR -----END PGP SIGNATURE-----

1 0

Simplifying load balancing by removing Guard+Exit?
by Mike Perry 28 Sep '15

28 Sep '15

Hey all, I am playing with the load balancing equations in 3.8.3 in dir-spec.txt (https://gitweb.torproject.org/torspec.git/tree//dir-spec.txt#n2454) in order to account for padding, hidden/onion services, and directory traffic, and I've noticed that the fact that nodes can be both Exits and Guards not only vastly complicates the current equations, but will make any attempt at accounting for this additional overhead nearly impossible. If you've previously tried to understand the current load balancing equations, or wondered why they have 3 major sub-cases and roughly 9 sub-cases, this is entirely to account for Guard+Exit nodes, and to handle relative scarcity of pure Guard and pure Exit nodes in various conditions. Removing the Guard+Exit ('D') nodes makes all of those cases condense to one single, simple set of solutions: ⎧ E + G + M E + G + M 2⋅E - M - G 2⋅G - M - E ⎫ ⎨Wee: ─────────, Wgg: ─────────, Wme: ───────────, Wmg: ────────────⎬ ⎩ 3⋅E 3⋅G 3⋅E 3⋅G ⎭ No missing constraints, no sub-cases, no boundary conditions. Easy to reason about. Easy to intuitively convince yourself that the solutions are correct. What I want to do is add two variables to the consensus that allow us to specify expected (or measured) overhead at Guard nodes (G_o) and at Middle nodes (M_o). These two variables would represent the sum of padding, directory overhead, and hidden service traffic experienced by Guard and Middle nodes, respectively. If we ignore Guard+Exit nodes, this makes the load balancing equations become: (1-G_o)*Wgg*G == (1-M_o)*(M + Wme*E + Wmg*G) # Guard bw == middle bw (1-G_o)*Wgg*G == Wee*E # Guard bw == exit bw Wmg*G + Wgg*G == G # Guards can be middles or Guards Wme*E + Wee*E == E # Exits can be middles or Exits These solutions are a bit longer so I won't paste them here, but they are still reasonable if we ditch the Guard+Exit idea. They can be simplified even further by using a similar approach as the GuardFraction idea from Proposal 236 (Section 1.3): We can simply adjust each Guard's bandwidth by G_o either before solving the equations, or by adjusting Wgg and Wmg after the solution, then we only need to include the (1-M_o) factor in the equations themselves. We can't really do this simplification if we keep Guard+Exit, because of the interplay between Exit and Guard weights in the system of equations and cases. Additionally, if we keep Guard+Exit, the solutions literally consume an entire page of text to represent symbolically, and the sub-cases become even more complicated to evaluate and check for proper bounds and correctness. In fact, George has already run into such edge cases while trying to implement Proposal 236 (See https://trac.torproject.org/projects/tor/ticket/16255) Moreover, I've been thinking about the surveillance incentives for Guard+Exit nodes, and I actually think it is a net risk to the network for nodes to be both Guards and Exits. It's easy to find an excuse to watch an Exit node. If anything bad ever happens from an Exit, you may be able to convince someone to let you keep an eye on it** "just in case". A Guard-only node shouldn't cause anybody any problems, though, and should be much harder to justify monitoring. So this means that Guard+Exit nodes allow an adversary to justify monitoring large portions of both the entry and exit traffic of the network without any strange/technical/esoteric arguments about the need to perform complicated statistical attacks with questionable accuracy and high collateral damage, and instead force them to justify their monitoring another way. I also hear from large node operators that it is still the Exit flag that causes their nodes to really become overloaded, so if that's actually true, then it's likely that Exit nodes make poor Guards anyway, especially if Exit bandwidth is scarce (which it often is). So, what do people think? Does anyone violently disagree with removing the Guard flag from Guard+Exit nodes? ** I used to run an Exit node, and my lawyer at the time was told exactly this at one point during a police visit about a nonsensical bomb threat to some 4chan equivalent. He was specifically told "We will be monitoring this node from now on" by one of the visiting officers. I was unable to ever discover what that actually meant, and the EFF unfortunately did not feel it was worth pursuing to help me find out. It may have been a scare tactic, but it could just as easily have not been, and for all I know they may have been actually able to convince a judge to let them do this. -- Mike Perry

3 2

Two new Onionoo versions 2.4 and 2.5 add new "effective_family" and "measured" fields
by Karsten Loesing 27 Sep '15

27 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I was reminded by Harmony that I said a while back [0] that I would announce new Onionoo versions on this list and not only in private message to Harmony for including them in the next TWN issue. Oops. So, version 2.4 added a new "effective_family" field to details documents, listing all the relays with which the relay in question is in an effective, mutual family relationship. The main goal here is to make it easier to detect misconfigured relay families. This can be relay operators or friendly people watching over the Tor network and reminding relay operators to fix their configurations. [1] The new version 2.5 that I deployed this week adds the optional "measured" field to details documents. The main idea behind this new field is that relay operators and Tor network debuggers can now figure out easily whether a relay is affected by not being measured by a sufficient number of bandwidth authorities and as a result has lower usage than it could handle. This field is not yet displayed by the Onionoo clients Atlas or Globe, but it's accessible via Onionoo's API [2]. More details are on ticket #16020 [3]. All the best, Karsten [0] onionoo-announce@ posting from April 27, 2015 [1] https://lists.torproject.org/pipermail/tor-news/2015-August/000109.html [2] https://onionoo.torproject.org/protocol.html#details [3] https://trac.torproject.org/projects/tor/ticket/16020 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV1HYeAAoJEJD5dJfVqbCrFJAIAIQYIC0CiSx6GJJikQ6CTxgw +AljFxABfnLtHu58EtBLx1jRJo0u9fStCMA/YFWLiq3FmEhCb5YvoL4zwa92PwlN bIoEricgq3sXjOm6TxJ75/6OBeH8AVIsah6qxHFkVfCPwjmt0bsDyaE7VqlCv2tN tAunIZcDyhsStGOOErr5uc9FHgPquvb66Iy7YFwnJxioMRE3yp4GBTDv78WyUEuR TZOWBh/cbJYrwSu5b+vU3C+t9eAI9ErQ8BDYlwy0C6zgJO+paSUkxWkCvuI3nv2l e/Ol6M40c9syZEb5jexn3K3NTOpJCKKhjXoXtP7UHXz8ZSdhZw2gxi31ZXYrSkQ= =/rwg -----END PGP SIGNATURE-----

3 3

Tor on iOS 9
by Conrad Kramer 27 Sep '15

27 Sep '15

Hi all! I'm new to the list, my name is Conrad. As some of you may or may not have heard, Apple's latest version of iOS enables functionality that allows for a system-wide Tor client. A few people in the community, myself included, started working on a project to get this client into the App Store. I wrote up a small document (attached) that explains the project in detail, so that you can learn about it if you're interested! I'm very excited to get Tor into the hands of many more users. Conrad

1 0

0.2.8 triage at dev meeting!
by Isabela 25 Sep '15

25 Sep '15

Hello everyone! We are planing on doing a triage session for 0.2.8 release in Berlin! Below is some guidance of what you can do to prepare for that, also what you can do if you are planning on being there but want to help build the release. Who should participate? Core Tor developers, obfuscation developers, Tor Browser developers, Hidden Services developers, and of course anyone else To help with the triage we are asking everyone to add the following information to tickets you think should be part of 0.2.8 * keyword field: 0.2.8.x-triage * Size field: an estimation of how long you think it will take to get it done (not counting review time, just execution): * small < 1 day * medium < 1 week * large > 1 week * Priority field: * blocker * critical * major * normal * minor * trivial * Sponsor field: if it's related to a sponsor deliverable For 0.2.7 triage we did a few rounds until we ended with a good chunk of work for the release. The release is coming out this month and here is some numbers related to it if you would like to use as a reference: https://storm.torproject.org/shared/TLgTuwGNswrIbfhj9NUctPKj6iG9V7KGHpwy7yz… I will send more updates on how this first triage session will be done in Berlin and how we will get remote folks to participate. Also, this does not mean what we do in Berlin is final, things can be refined after too. Cheers, Isabela -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

4 4

Desired exit node diversity
by Virgil Griffith 24 Sep '15

24 Sep '15

Let's try a simple special case. In an idealized Tor network, what would the distribution of exit nodes look like? * Would each exit node have the same bandwidth? Or would there instead be only one exit node per AS? * Would the number of exit nodes constitute exactly 1/3 of all Tor nodes? Would the total exit node bandwidth constitute 1/3 of all Tor bandwidth? * Would their distribution of AS numbers match the distribution of AS numbers of Tor clients? The distribution of Internet users? Exit nodes seem a nice place to start concretizing what's meant when we say we want relay diversity. Comments immensely appreciated because as-is I don't know the answers to these questions. -V

8 11

[Measurement Team] Next IRC meeting happens on Thursday, Sep 24, 14:00 UTC in #tor-dev
by Karsten Loesing 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Thursday, September 24, 2015, 14:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150924T14 This will be the last IRC meeting before the Berlin dev meeting. Maybe we'll hold an in-person team meeting next week at the same time. We'll resume the IRC meeting format the week after. Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWArn+AAoJEJD5dJfVqbCrm/YIAMTJvTAPpmbg0B85By/GfzLL mtTRB108vCLl+mkAOOkefo3o0u7RXcGlWeuSIUsqfoS4AcNpKVTF8dMrOyxCm80c nIOcwC8QX9gHGNXJXKIXaDCSeZ5MRcSLa2gLpllc/M844LbrfILIVQiF9AKafEiM DhJ7Hw41E9dNma1Qfm8LQXYwd9Sp1DLjRIFuGs3hOurZH9b2H+9Z9S+8M4D0I/hM FDyDo11MbRHEWcombVAX6IdkCUBjcZnjOUIu3tvca3pvf67or3gsRKI1GCLIRwan /Ff5TxDPkltTQwmU2E4xLpuI09baKcRpdiInkrsg1E6JfH1tT2VESJxNYb+1STM= =QMdU -----END PGP SIGNATURE-----

1 0

Looking for resources
by TOR USER 22 Sep '15

22 Sep '15

Hello, I was going through the Tor proposals which have now been closed. I have been looking for discussion regarding those proposals (here - https://gitweb.torproject.org/torspec.git) Could you link me to some discussion threads because I couldn't find much on them? Thank you

2 1