[or-cvs] r8926: fix typos and a few subsections in roadmap-2007 (tor/trunk/doc/design-paper)
arma at seul.org
arma at seul.org
Fri Nov 10 04:52:43 UTC 2006
Author: arma
Date: 2006-11-09 23:52:39 -0500 (Thu, 09 Nov 2006)
New Revision: 8926
Modified:
tor/trunk/doc/design-paper/roadmap-2007.pdf
tor/trunk/doc/design-paper/roadmap-2007.tex
tor/trunk/doc/design-paper/tor-design.bib
Log:
fix typos and a few subsections in roadmap-2007
Modified: tor/trunk/doc/design-paper/roadmap-2007.pdf
===================================================================
(Binary files differ)
Modified: tor/trunk/doc/design-paper/roadmap-2007.tex
===================================================================
--- tor/trunk/doc/design-paper/roadmap-2007.tex 2006-11-10 04:21:57 UTC (rev 8925)
+++ tor/trunk/doc/design-paper/roadmap-2007.tex 2006-11-10 04:52:39 UTC (rev 8926)
@@ -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 @@
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 @@
\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 @@
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 @@
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 @@
\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 @@
%
% 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 @@
\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 @@
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 @@
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 @@
\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 @@
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 @@
\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 @@
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 @@
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.
Modified: tor/trunk/doc/design-paper/tor-design.bib
===================================================================
--- tor/trunk/doc/design-paper/tor-design.bib 2006-11-10 04:21:57 UTC (rev 8925)
+++ tor/trunk/doc/design-paper/tor-design.bib 2006-11-10 04:52:39 UTC (rev 8926)
@@ -199,9 +199,15 @@
@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}},
}
+ at 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,
author = {M{\"o}ller, Bodo},
title = {Provably Secure Public-Key Encryption for Length-Preserving Chaumian Mixes},
@@ -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 @@
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 @@
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,9 +1317,16 @@
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}},
}
+ at 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:
%%% mode: latex
%%% TeX-master: "tor-design"
More information about the tor-commits
mailing list