diff options
| -rw-r--r-- | doc/design-paper/roadmap-2007.pdf | bin | 114383 -> 119579 bytes | |||
| -rw-r--r-- | doc/design-paper/roadmap-2007.tex | 92 | ||||
| -rw-r--r-- | doc/design-paper/tor-design.bib | 29 |
3 files changed, 75 insertions, 46 deletions
diff --git a/doc/design-paper/roadmap-2007.pdf b/doc/design-paper/roadmap-2007.pdf Binary files differindex 081f981b3..16c28b74b 100644 --- a/doc/design-paper/roadmap-2007.pdf +++ b/doc/design-paper/roadmap-2007.pdf diff --git a/doc/design-paper/roadmap-2007.tex b/doc/design-paper/roadmap-2007.tex index 39fe8f5c0..16ae76eaf 100644 --- a/doc/design-paper/roadmap-2007.tex +++ b/doc/design-paper/roadmap-2007.tex @@ -1,5 +1,7 @@ \documentclass{article} +\usepackage{url} + \newenvironment{tightlist}{\begin{list}{$\bullet$}{ \setlength{\itemsep}{0mm} \setlength{\parsep}{0mm} @@ -24,17 +26,17 @@ \section{Introduction} -Hi, Roger! Hi, Shava. This paragraph should get deleted soon. Right now, -this document goes into about as much detail as I'd like to go into for a -technical audience, since that's the audience I know best. It doesn't have -time estimates everywhere. It isn't well prioritized, and it doesn't -distinguish well between things that need lots of research and things that -don't. The breakdowns don't all make sense. There are lots of things where -I don't make it clear how they fit into larger goals, and lots of larger -goals that don't break down into little things. It isn't all stuff we can do -for sure, and it isn't even all stuff we can do for sure in 2007. The -tmp\{\} macro indicates stuff I haven't said enough about. That said, here -plangoes... +%Hi, Roger! Hi, Shava. This paragraph should get deleted soon. Right now, +%this document goes into about as much detail as I'd like to go into for a +%technical audience, since that's the audience I know best. It doesn't have +%time estimates everywhere. It isn't well prioritized, and it doesn't +%distinguish well between things that need lots of research and things that +%don't. The breakdowns don't all make sense. There are lots of things where +%I don't make it clear how they fit into larger goals, and lots of larger +%goals that don't break down into little things. It isn't all stuff we can do +%for sure, and it isn't even all stuff we can do for sure in 2007. The +%tmp\{\} macro indicates stuff I haven't said enough about. That said, here +%plangoes... Tor (the software) and Tor (the overall software/network/support/document suite) are now experiencing all the crises of success. Over the next year, @@ -62,7 +64,7 @@ With protocol versioning support would come the ability to {\bf future-proof directory protocol, is pretty firmly tied to the SHA-1 hash function, which though not yet known to be insecure for our purposes, has begun to show its age. We should -remove assumptions thoughout our design based on the assumption that public +remove assumptions throughout our design based on the assumption that public keys, secret keys, or digests will remain any particular size indefinitely. Our OR {\bf authentication protocol}, though provably @@ -143,12 +145,13 @@ they are to be deployed in 2008.\plan{Design in 2007; unknown difficulty. \subsubsection{Relay incentives} To support more users on the network, we need to get more servers. So far, we've relied on volunteerism to attract server operators, and so far it's -served us well. But in the long run, we need to {\bf design incentices for +served us well. But in the long run, we need to {\bf design incentives for users to run servers} and relay traffic for others. Most obviously, we could try to build the network so that servers offered improved service for other servers, but we would need to do so without weakening anonymity and making it obvious which connections originate from users running servers. We -have some preliminary designs here~\cite{challenges}, but need to perform +have some preliminary designs here~\cite{tor-challenges}~\cite{incentives-txt}, +but need to perform some more research to make sure they would be safe and effective.\plan{Write a draft paper; 2 person-months.} @@ -235,12 +238,13 @@ all getting dropped on the floor, the TCP push-back mechanisms don't really transmit this information back to the incoming streams.\plan{Do in 2007 since related to bandwidth limiting. 3-4 weeks.} - \subsection{Running Tor as both client and server} -\tmp{many performance tradeoffs and balances that need more attention. - Roger, please write.} \plan{No idea; try profiling and improving things in - 2007.} +Many performance tradeoffs and balances that might need more attention. +We first need to track and fix whatever bottlenecks emerge; but we also +need to invent good algorithms for prioritizing the client's traffic +without starving the server's traffic too much.\plan{No idea; try +profiling and improving things in 2007.} \subsection{Protocol redesign for UDP} Tor has relayed only TCP traffic since its first versions, and has used @@ -249,7 +253,7 @@ in the long term we will need to allow UDP traffic on the network, and switch some or all of the network to using a UDP transport. {\bf Supporting UDP traffic} will make Tor more suitable for protocols that require UDP, such as many VOIP protocols. {\bf Using a UDP transport} could greatly reduce -resource limitations on servers, and make the network far less interruptable +resource limitations on servers, and make the network far less interruptible by lossy connections. Either of these protocol changes would require a great deal of design work, however. We hope to be able to enlist the aid of a few talented graduate students to assist with the initial design and @@ -365,7 +369,7 @@ unacceptable levels. %Cite something \plan{Start doing this in 2007; write a paper. 8-16 weeks.} We've got some preliminary results suggesting that {\bf a topology-aware - routing algorithm}~\cite{routing-zones} could reduce Tor users' + routing algorithm}~\cite{feamster:wpes2004} could reduce Tor users' vulnerability against local or ISP-level adversaries, by ensuring that they are never in a position to watch both ends of a connection. We need to examine the effects of this approach in more detail and consider side-effects @@ -381,12 +385,12 @@ Internet. \plan{Not in 2007 unless a graduate student wants to do it.} % % See above; I think I got this. -We should research the efficacy of {\bf website fingperprinting} attacks, +We should research the efficacy of {\bf website fingerprinting} attacks, wherein an adversary tries to match the distinctive traffic and timing pattern of the resources constituting a given website to the traffic pattern of a user's client. These attacks work great in simulations, but in practice we hear they don't work nearly as well. We should get some actual -numbers to investigte the issue, and figure out what's going on. If we +numbers to investigate the issue, and figure out what's going on. If we resist these attacks, or can improve our design to resist them, we should. % add cites \plan{Possibly part of end-to-end correlation paper. Otherwise, not in 2007 @@ -468,9 +472,9 @@ adding named nodes to the network.\plan{Do in 2007; 4-5 weeks.} \subsection{Protocol security} In addition to other protocol changes discussed above, -% And should we move somve of them down here? -NM +% And should we move some of them down here? -NM we should add {\bf hooks for denial-of-service resistance}; we have some -prelimiary designs, but we shouldn't postpone them until we realy need them. +preliminary designs, but we shouldn't postpone them until we really need them. If somebody tries a DDoS attack against the Tor network, we won't want to wait for all the servers and clients to upgrade to a new version.\plan{Research project; do this in 2007 if funded.} @@ -499,7 +503,7 @@ testing framework.\plan{Ongoing basis, time permitting.} We should also write flexible {\bf automated single-host deployment tests} so we can more easily verify that the current codebase works with the -network.\plan{Worthwile in 2007; would save lots of time. 2-4 weeks.} +network.\plan{Worthwhile in 2007; would save lots of time. 2-4 weeks.} We should build automated {\bf stress testing} frameworks so we can see which realistic loads cause Tor to perform badly, and regularly profile Tor against @@ -559,13 +563,13 @@ current Tor-friendly position.\plan{Do a writeup here in 2007; 1-2 weeks.} Those who do block Tor users also block overbroadly, sometimes blacklisting operators of Tor servers that do not permit exit to their services. We could obviate innocent reasons for doing so by designing a {\bf narrowly-targeted Tor - RBL service} so that those who wanted to overblock Tor clould no longer + RBL service} so that those who wanted to overblock Tor could no longer plead incompetence.\plan{Possibly in 2007 if we decide it's a good idea; 3 weeks.} \subsection{All-in-one bundle} We need a well-tested, well-documented bundle of Tor and supporting -applications configured to use it correctly. We have an intial +applications configured to use it correctly. We have an initial implementation well under way, but it will need additional work in identifying requisite Firefox extensions, identifying security threats, improving user experience, and so on. This will need significantly more work @@ -578,12 +582,17 @@ is quite feasible, but their project is not currently maintained. \subsection{A Tor client in a VM} \tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment -section below . Roger, can you write this? +section below. JanusVM is a Linux kernel running in VMWare. It gets an IP +address from the network, and serves as a DHCP server for its host Windows +machine. It intercepts all outgoing traffic and redirects it into Privoxy, +Tor, etc. This Linux-in-Windows approach may help us with scalability in +the short term, and it may also be a good long-term solution rather than +accepting all security risks in Windows. %\subsection{Interface improvements} %\tmp{Allow controllers to manipulate server status.} % (Why is this in the User Experience section?) -RD -% I think it's better left to a generic ``make controller iface bettter'' item. +% I think it's better left to a generic ``make controller iface better'' item. \subsection{Firewall-level deployment} Another useful deployment mode for some users is using {\bf Tor in a firewall @@ -596,16 +605,19 @@ and to {\bf construct a recommended set of firewall configurations} to redirect traffic to Tor. This is an area where {\bf deployment via a livecd}, or an installation -targetted at specialized home routing hardware, could be useful. +targeted at specialized home routing hardware, could be useful. \subsection{Assess software and configurations for anonymity risks} Right now, users and packagers are more or less on their own when selecting -firefox extensions. We should {\bf assemble a recommended list of browser +Firefox extensions. We should {\bf assemble a recommended list of browser extensions} through experiment, and include this in the application bundles we distribute. We should also describe {\bf best practices for using Tor with each class of - application}. \tmp{Roger, say more} + application}. For example, Ethan Zuckerman has written a detailed +tutorial on how to use Tor, Firefox, GMail, and Wordpress to blog with +improved safety. There are many other cases on the Internet where anonymity +would be helpful, and there are a lot of ways to screw up using Tor. The Foxtor and Torbutton extensions serve similar purposes; we should pick a favorite, and merge in the useful features of the other. @@ -632,10 +644,16 @@ translators only need to use a single tool to translate the whole Tor suite. \section{Support} -\tmp{would be nice to set up some actual user support infrastructure, especially -focusing on server operators and on coordinating volunteers.} Roger, can you -write this ? I don't know what ``user support infrastructure'' is. +It would be nice to set up some {\bf user support infrastructure} and +{\bf contributor support infrastructure}, especially focusing on server +operators and on coordinating volunteers. +This includes intuitive and easy ticket systems for bug reports and +feature suggestions (not just mailing lists with a half dozen people +and no clear roles for who answers what), but it also includes a more +personalized and efficient framework for interaction so we keep the +attention and interest of the contributors, and so we make them feel +helpful and wanted. \section{Documentation} @@ -656,7 +674,7 @@ We should {\bf revise our design paper} to reflect the new decisions and research we've made since it was published in 2004. This will help other researchers evaluate and suggest improvements to Tor's current design. -Other projects sometimes implement the client side of our prototocol. We +Other projects sometimes implement the client side of our protocol. We encourage this, but we should write {\bf a document about how to avoid excessive resource use}, so we don't need to worry that they will do so without regard to the effect of their choices on server resources. @@ -665,7 +683,7 @@ without regard to the effect of their choices on server resources. Our documentation falls into two broad categories: some is `discoursive' and explains in detail why users should take certain actions, and other -documenation is `comprehensive' and describes all of Tor's features. Right +documentation is `comprehensive' and describes all of Tor's features. Right now, we have no document that is both deep, readable, and thorough. We should correct this by identifying missing spots in our design. diff --git a/doc/design-paper/tor-design.bib b/doc/design-paper/tor-design.bib index 0309bb189..c2836f98d 100644 --- a/doc/design-paper/tor-design.bib +++ b/doc/design-paper/tor-design.bib @@ -199,7 +199,13 @@ @Misc{tor-spec, author = {Roger Dingledine and Nick Mathewson}, title = {Tor Protocol Specifications}, - note = {\url{http://freehaven.net/tor/tor-spec.txt}}, + note = {\url{http://tor.eff.org/svn/trunk/doc/tor-spec.txt}}, +} + +@Misc{incentives-txt, + author = {Roger Dingledine and Nick Mathewson}, + title = {Tor Incentives Design Brainstorms}, + note = {\url{http://tor.eff.org/svn/trunk/doc/incentives.txt}}, } @InProceedings{BM:mixencrypt, @@ -1119,8 +1125,7 @@ number = {2}, year = {2003}, month = {Sept}, - www_pdf_url = {http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf}, - www_section = {Anonymous communication}, + note = {\url{http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf}}, } @inproceedings{tor-design, @@ -1220,9 +1225,8 @@ year = {2006}, month = {June}, address = {Cambridge, UK}, - www_section = {Economics}, bookurl = {http://weis2006.econinfosec.org/}, - www_pdf_url = {http://freehaven.net/doc/wupss04/usability.pdf}, + note = {\url{http://freehaven.net/doc/wupss04/usability.pdf}}, } @Misc{six-four, @@ -1240,7 +1244,7 @@ address = {Cambridge, UK}, publisher = {Springer}, bookurl = {http://petworkshop.org/2006/}, - www_pdf_url = {http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf}, + note = {\url{http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf}}, } @Misc{zuckerman-threatmodels, @@ -1292,7 +1296,7 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez}, school = {Harvard University}, year = {2006}, month = {July}, - www_pdf_url = {http://afs.eecs.harvard.edu/~goodell/thesis.pdf}, + note = {\url{http://afs.eecs.harvard.edu/~goodell/thesis.pdf}}, } @inproceedings{tap:pet2006, @@ -1304,7 +1308,7 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez}, address = {Cambridge, UK}, publisher = {Springer}, bookurl = {http://petworkshop.org/2006/}, - www_pdf_url = {http://petworkshop.org/2006/preproc/preproc_18.pdf}, + note = {\url{http://www.cypherpunks.ca/~iang/pubs/torsec.pdf}}, } @inproceedings{rep-anon, @@ -1313,7 +1317,14 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez}, booktitle = {Proceedings of Workshop on Economics of Peer-to-Peer Systems}, year = {2003}, month = {June}, - www_pdf_url = {http://freehaven.net/doc/econp2p03/econp2p03.pdf}, + note = {\url{http://freehaven.net/doc/econp2p03/econp2p03.pdf}}, +} + +@misc{tor-challenges, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + title = {Challenges in deploying low-latency anonymity}, + year = {2005}, + note = {Manuscript} } %%% Local Variables: |