(This post is likely to be interesting for folks who want to know how the Tor software is made.) At the core of the Tor software lies the network protocol that Tor relays and clients use to talk to each other. We try to make sure we have a good set of specification documents for the protocol at all times, so that other people can write compatible software that interoperates with Tor. Once upon a time, we used to change these specification documents whenever we changed the software's behavior. That didn't go well. We would have changes in the spec that we had forgotten to make in the software, and tons of inline comments where we argued about whether a particular paragraph was a good idea. So back in 2007, we introduced a lightweight change-proposal process: to make a change to the Tor protocol, you write up a little design document, and send it to the tor-dev mailing list. Once it meets editorial quality, it can go into the proposals repository. Once it's implemented, it can be merged into the spec. There are a lot of proposals to look at, though. The current set of open proposals has almost 100,000 words in it! (That's almost half again as long as the Tor specs themselves.) To help people navigate through this pile of design proposals, I started to write a regular "proposal status" email to explain what all of the open proposals are about. Last year, however, I fell out of the habit. Tonight, I've tried to fall back in: here's the latest proposal status writeup. Below the cut, my summaries of the still-open proposals that have been added in the past couple of year -- and thanks to all the busy designers who have been working to think of ways to improve Tor! 228 Cross-certifying identity keys with onion keys This proposal signs each server's identity key with its onion keys, to prove onion key ownership in the router descriptor. It's not clear that this actually improves security, but it fixes an annoying gap in our key authentication. I have it coded up in my #12498 branch, targeting 0.2.7. (2/2015) 229 Further SOCKS5 extensions Here's a nice idea for how we can support a new SOCKS5 protocol extension to relay information between clients and Tor, and between Tor and pluggable transports, more effectively. It also adds some additional SOCKS5 error codes. There are some open questions to answer. "Trunnel" has an implementation of the protocol extension formats in its examples directory. (2/2015) 230 How to change RSA1024 relay identity keys [DRAFT] 231 Migrating authority RSA1024 identity keys [DRAFT] Who remembers the OpenSSL "Heartbleed" vulnerability? These proposals I wrote try to explain safer mechanisms for a bunch of servers to migrate their RSA1024 identity keys at once. I'm not sure we'll be able to build thee, though: implementating proposal 220 above seems cleverer to me. (2/2015) 232 Pluggable Transport through SOCKS proxy [OPEN] Arturo Filastò wrote this proposal for chaining pluggable transports which themselves need to go through proxies. Seems potentially useful! (2/2015) 233 Making Tor2Web mode faster [OPEN] This one by Virgil, Fabio, and Giovanni describes a couple of ways that Tor2Web builds of Tor can save some circuit hops that they use today. Potentially useful for Tor2Web; any implementation needs to be sure that it never changes the behavior of non-tor2web clients. (2/2015) 234 Adding remittance field to directory specification [OPEN] Virgil, Leif, and Rob added this proposal for relays to specify payment addresses for schemes that want to compensate relay operators for their use of bandwidth. (2/2015) 235 Stop assigning (and eventually supporting) the Named flag [DRAFT] This proposal is about removing the Named flag. (Thanks to Sebastian Hahn for writing it!) The rationale is that the naming system for relays never worked particularly well, and it had strange and hard-to-explain security properties. We've implemented the key part of this already: directory authorities don't assign the Named flag any longer. Next up will be removing client support for parsing and understanding it. (2/2015) 236 The move to a single guard node [OPEN] This proposal suggests that to limit client fingerprinting, and to limit opportunities for attacks, clients should use a single guard node, rotated infrequently. This transition is in progress; we use a single guard node for circuit traffic now, but in order to make guards more long-lived, we need to adjust how they are chosen. George has a patch for that as #9321, targetting inclusion into 0.2.6. (Thanks to George Kadianakis and Nicholas Hopper for writing this one.) (2/2015) 237 All relays are directory servers [OPEN] Matthew Finkel wrote this proposal to describe a transition to a world where Tor relays can be directory servers without having an open DirPort -- and eventually, where every relay can be a DirServer. He has an implementation, possibly for 0.2.6 or 0.2.7, in ticket #12538. (2/2015) 238 Better hidden service stats from Tor relays [DRAFT] Here's an important one that needs many eyes. George Kadianakis, David Goulet, Karsten Loesing, and Aaron Johnson wrote this to describe a mechanism for the tor network to securely produce aggregate hidden service usage statistics without exposing sensitive intermediate results. This has an implementation in 0.2.6 and should probably be marked closed. (2/2015) 239 Consensus Hash Chaining [DRAFT] Here's the start of a good idea that Andrea Shepard wrote up (with some help from Nick). The idea is to make it hard even for a set of corrupt authorities (or authority-key-thieves) to make a personalized false consensus for a target user, by authenticating the whole sequence as a hash chain. Others on tor-dev suggested improvements and had good questions (thanks, Leif and Sebastian G!) (2/2015) 240 Early signing key revocation for directory authorities [DRAFT] This one is another Andrea+Nick collaboration about certificate revocation for our most sensitive keys. If an authority key needs to be replaced, it would be great to take the old one out of circulation as fast as possible. Peter Palfrader on tor-dev had some ideas for making this better. (2/2015) 241 Resisting guard-turnover attacks [DRAFT] I wrote this one with good ideas from Aaron Johnson and Rob Jansen. It describes a way to respond to an important class of attacks where an adversary kills off a targeted user's guards until the user has chosen a guard the attacker controls. (See the "Sniper Attack") paper. The defense is tricky, and if not done right, might lead clients to kick themselves off the network out of paranoia. So, this proposal could use more analysis. (2/2015) Continue reading...
