[or-cvs] Turn more thoughts into text. Next: filesharing.

[Nick Mathewson]

Update of /home/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/tmp/cvs-serv5304

Modified Files:
	challenges.tex 
Log Message:
Turn more thoughts into text.  Next: filesharing.

Index: challenges.tex
===================================================================
RCS file: /home/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- challenges.tex	28 Jan 2005 22:53:54 -0000	1.19
+++ challenges.tex	29 Jan 2005 01:05:09 -0000	1.20
@@ -33,26 +33,31 @@
 to be practical and usable for protecting TCP streams over the
 Internet~\cite{tor-design}. We have been operating a publicly deployed
 Tor network since October 2003 that has grown to over a hundred volunteer
-nodes and carries over 70 megabits per second of average traffic.
+nodes and carries an average over 70 megabits of traffic per second.
 
 Tor has a weaker threat model than many anonymity designs in the
-literature, because we aim primarily to provide a
-practical and useful network. Given that fixed assumption, we then
+literature, because our foremost goal is to deploy
+practical and useful network for interactive (low-latency) communications.
+Subject to this restriction, we try
 provide as much anonymity as we can. In particular, because we
-want to support interactive communications, we fall prey to a variety
+support interactive communications without impractically expensive padding,
+we fall prey to a variety
 of intra-network~\cite{danezis-oakland,flow-correlation04,bar} and
-end-to-end~\cite{danezis-pet2004,SS03} anonymity breaking attacks.
+end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
 
-Tor's defense lies in having a diverse enough network that its adversaries
-are unlikely to be in the right places to attack both ends of a user's
-stream. Specifically,
+Tor defends against a user against adversaries so long as they are unable to
+observe her connections as they enter and leave the Tor network.
+Therefore, Tor's
+defense lies in having a diverse enough network to prevent adversaries
+that are unlikely to be in the right places to attack users.
+Specifically,
 Tor aims to resist observers and insiders by distributing each transaction
 over several nodes in the network.  This ``distributed trust'' approach
 means the Tor network can be safely operated and used by a wide variety
 of mutually distrustful users, providing more sustainability and security
-than previous attempts at anonymizing networks.
+than some previous attempts at anonymizing networks.
 The Tor network has a broad range of users, including ordinary citizens
-who want to avoid being profiled for targeted advertisements, corporations
+concerned about their privacy, corporations
 who don't want to reveal information to their competitors, and law
 enforcement and government intelligence agencies who need
 to do operations on the Internet without being noticed.
@@ -69,6 +74,23 @@
 interests helps maintain both the stability and the security of the
 network.
 
+Tor's principal research strategy in attempting to deploy a network that
+practical, useful, and anonymous, has been to insist, when trade-offs arise
+between these properties, on remaining useful enough to attract as many users
+as possible, and practical enough to support them.  Subject to these
+constraints, we aim to maximize anonymity.  This is not the only possible
+direction in anonymity research: designs exist that provide more anonymity
+than Tor at the expense of significantly increased resource requirements, or
+decreased flexibility in application support (typically because of increased
+latency).  Such research does not typically abandon aspirations towards
+deployability or utility, but instead tries to maximize deployability and
+utility subject to a certain degree of anonymity.  We believe that these
+approaches can be promising and useful, but that by focusing on deploying a
+usable system in the wild, Tor helps us experiment with the actual parameters
+of what makes a system ``practical'' for volunteer operators and ``useful''
+for home users, and helps illuminate undernoticed issues which any deployed
+volunteer anonymity network will need to address.
+
 While~\cite{tor-design} gives an overall view of the Tor design and goals,
 this paper describes the policy and technical issues that Tor faces are
 we continue deployment. We aim to lay a research agenda for others to
@@ -127,9 +149,12 @@
 %censorship. Nobody would be able to determine who was offering the site,
 %and nobody who offered the site would know who was posting to it.
 
-tor works for tcp on socks (see section \ref{subsec:tcp-vs-ip}). it
-only anonymizes the channel, so you need application-level scrubbers
-like privoxy.
+Tor attempts to anonymize the transport layer, not the application layer, so
+application protocols that include personally identifying information need
+additional application-level scrubbing proxies, such as
+Privoxy~\cite{privoxy} for HTTP.  Furthermore, Tor does not permit arbitrary
+IP packets; it only anonymizes TCP and DNS, and only supports cconnections
+SOCKS (see section \ref{subsec:tcp-vs-ip}).
 
 Tor differs from other deployed systems for traffic analysis resistance
 in its security and flexibility.  Mix networks such as
@@ -202,11 +227,46 @@
 
 \section{Threat model}
 
-discuss $\frac{c^2}{n^2}$, except how in practice the chance of owning
-the last hop is not $c/n$ since that doesn't take the destination (website)
-into account. so in cases where the adversary does not also control the
-final destination we're in good shape, but if he *does* then we'd be better
-off with a system that lets each hop choose a path.
+Tor does not attempt to defend against a global observer.  Any adversary who
+can see a user's connection to the Tor network, and who can see the
+corresponding connection as it exits the Tor network, can use the timing
+correlation between the two connections to confirm the user's chosen
+communication partners.  Defeating this attack would seem to require
+introducing a prohibitive degree of traffic padding between the user and the
+network, or introducing an unacceptable degree of latency (but see
+\ref{subsec:mid-latency} below).  Thus, Tor only
+attempts to defend against external observers who can observe both sides of a
+user's connection.
+
+Against internal attackers, who sign up Tor servers, the situation is more
+complicated.  In the simplest case, if an adversary has compromised $c$ of
+$n$ servers on the Tor network, then the adversary will be able to compromise
+a random circuit with probability $\frac{c^2}{n^2}$ (since the circuit
+initiator chooses hops randomly).  But there are
+complicating factors:
+\begin{tightlist}
+\item If the user continues to build random circuits over time, an adversary
+  is pretty certain to see a statistical sample of the user's traffic, and
+  thereby can build an increasingly accurate profile of her behavior.  (See
+  \ref{subsec:helper-nodes} for possible solutions.)
+\item If an adversary controls a popular service outside of the Tor network,
+  he can be certain of observing all connections to that service; he
+  therefore will trace connections to that service with probability
+  $\frac{c}{n}$.
+\item Users do not in fact choose servers with uniform probability; they
+  favor servers with high bandwidth, and exit servers that permit connections
+  to their favorite services.
+\end{tightlist}
+
+%discuss $\frac{c^2}{n^2}$, except how in practice the chance of owning
+%the last hop is not $c/n$ since that doesn't take the destination (website)
+%into account. so in cases where the adversary does not also control the
+%final destination we're in good shape, but if he *does* then we'd be better
+%off with a system that lets each hop choose a path.
+%
+%Isn't it more accurate to say ``If the adversary _always_ controls the final
+% dest, we would be just as well off with such as system.'' ?  If not, why
+% not? -nm
 
 in practice tor's threat model is based entirely on the goal of dispersal
 and diversity. george and steven describe an attack \cite{draft} that
@@ -234,17 +294,16 @@
 launch their attacks, and they found that the defenders were recognizing
 attacks because they came from the same IP space. These engineers wanted
 to use Tor to hide their tracks. First, from a technical standpoint,
-Tor does not support the variety of IP packets they would like to use in
+Tor does not support the variety of IP packets one would like to use in
 such attacks (see Section \ref{subsec:ip-vs-tcp}). But aside from this,
 we also decided that it would probably be poor precedent to encourage
-such use -- even legal use that improves national security -- and managed
+such use---even legal use that improves national security---and managed
 to dissuade them.
 
 With this image issue in mind, here we discuss the Tor user base and
 Tor's interaction with other services on the Internet.
 
 
-
 \subsection{Usability}
 
 Usability: fc03 paper was great, except the lower latency you are the
@@ -446,6 +505,7 @@
 transport a greater variety of protocols.
 
 \subsection{Mid-latency}
+\label{subsec:mid-latency}
 
 Mid-latency. Can we do traffic shape to get any defense against George's
 PET2004 paper? Will padding or long-range dummies do anything then? Will