Future areas for Tor research

[Roger Dingledine]

[I'm moving this thread to or-dev from personal mail so we can be more
transparent for the rest of the Tor researchers out there. -RD]

Hi Steven, others,

Here are some research directions that come to mind. We should expand
on this list, and also try to prioritize by a) which ones we can make
progress on, b) which ones matter most, and c) which ones I'm anticipating
funders want done when. I've mostly sorted the list below by 'b' and 'c'.
Eventually the list could go up on the website as research.wml.

Thanks,
--Roger

By end of 2008:
- Paul's NRL project to evaluate path selection under various trust
  distributions. The idea is to figure out safer/better ways to build
  paths if we assume some users trust some relays more than others.
- Peter's proposal 141. How to trade off descriptor fetching overhead
  with circuit-building overhead. Are there even better ways?

By end of 2009:
- Understand the risks from letting people relay traffic through your
  Tor while you're also being a Tor client. Compare risks from being a
  bridge relay to risks from being a 'full' relay. Come up with practical
  ways to mitigate.
- Take Roger's incentive.pdf design, flesh it out further, and see if we
  can find solutions to the long-term intersection attack that arises
  from attackers being able to correlate "that relay is online everytime
  this anonymous high-priority user does an action." (I need to clean up
  incentive.pdf and send it to this list.)

By end of 2010:
- Better load balancing algorithms, path selection choices, etc.
  Building on Mike Perry's work and Steven's PETS 2008 paper. Do we
  do simulations? analysis? How to compare them? Are there cases when
  we can switch to 2-hop paths, or the variable-hop paths?
- Evaluate the latency and clogging attacks that are coming out, figure
  out if they actually work, and produce countermeasures.
- Tor network scalability, the easy version: use several parallel
  networkstatus documents, have algorithms for clients to pick which to
  use, for relays to get assigned to one, and make sure new designs like
  Peter's proposal 141 will be compatible with this.
- There's a vulnerability right now where you can enumerate bridges by
  running a non-guard Tor server and seeing who connects that isn't
  a known relay. One solution is to use two layers of guards, meaning
  bridge users use 4-hop paths. Is this the best option we've got? They
  don't want to be slowed down like that.
- How many bridges do you need to know to maintain reachability? We
  should measure the churn in our bridges. If there is lots of churn,
  are there ways to keep bridge users more likely to stay connected?
- Related, more bridge address distribution strategies: Steven and I
  were talking about a ``bridge loop'' design where bridge identities form
  a ``loop'' at the bridgeDB , and if you know any bridge in the loop you
  can learn all the others. This approach will allow Tor clients who know
  a few bridges to be updated with new bridges as their old ones rotate,
  without opening up the list to full enumeration.