[or-cvs] you guessed it, more edits

[arma@seul.org (Roger Dingledine)]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.tex 
Log Message:
you guessed it, more edits


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.96
retrieving revision 1.97
diff -u -d -r1.96 -r1.97
--- tor-design.tex	4 Nov 2003 08:30:10 -0000	1.96
+++ tor-design.tex	4 Nov 2003 08:34:50 -0000	1.97
@@ -116,24 +116,8 @@
 application-level proxies such as Privoxy \cite{privoxy}, without trying
 to duplicate those features itself.
 
-\item \textbf{Many TCP streams can share one circuit:} The
-original Onion Routing design built a separate circuit for each
-application-level request.  This hurt performance by requiring
-multiple public key operations for every request, and also presented
-a threat to anonymity from building so many different circuits; see
-Section~\ref{sec:maintaining-anonymity}.  Tor multiplexes multiple TCP
-streams along each virtual circuit to improve efficiency and anonymity.
-
-\item \textbf{Leaky-pipe circuit topology:} Through in-band signaling
-within the circuit, Tor initiators can direct traffic to nodes partway
-down the circuit. This novel approach allows for long-range
-padding to frustrate traffic shape and volume attacks at the initiator
-\cite{defensive-dropping}, and 
-also allows traffic to exit the circuit from the middle---thus
-frustrating traffic shape and volume attacks based on observing the end
-of the circuit.
-
-\item \textbf{No mixing, padding, or traffic shaping:} The original Onion
+\item \textbf{No mixing, padding, or traffic shaping yet:} The original
+Onion
 Routing design called for batching and reordering the cells arriving from
 each source. It also included padding between onion routers and, in a
 later design, between onion proxies (that is, users) and onion routers
@@ -148,6 +132,23 @@
 mixing that will improve anonymity against a realistic adversary, we
 leave these strategies out.
 
+\item \textbf{Many TCP streams can share one circuit:} The
+original Onion Routing design built a separate circuit for each
+application-level request.  This hurt performance by requiring
+multiple public key operations for every request, and also presented
+a threat to anonymity from building so many different circuits; see
+Section~\ref{sec:maintaining-anonymity}.  Tor multiplexes multiple TCP
+streams along each virtual circuit to improve efficiency and anonymity.
+
+\item \textbf{Leaky-pipe circuit topology:} Through in-band signaling
+within the circuit, Tor initiators can direct traffic to nodes partway
+down the circuit. This novel approach allows for long-range padding if
+future research indicates that it can frustrate traffic shape and volume
+attacks at the initiator \cite{defensive-dropping}, and
+also allows traffic to exit the circuit from the middle---again possibly
+frustrating traffic shape and volume attacks based on observing the end
+of the circuit.
+
 \item \textbf{Congestion control:} Earlier anonymity designs do not
 address traffic bottlenecks. Unfortunately, typical approaches to
 load balancing and flow control in overlay networks involve inter-node
@@ -237,16 +238,19 @@
 including {\bf Babel} \cite{babel}, {\bf Mixmaster}
 \cite{mixmaster-spec}, and
 {\bf Mixminion} \cite{minion-design}.  Because of this
-decision, these \emph{high-latency} networks are well-suited for anonymous
-email, but introduce too much lag for interactive tasks like web browsing,
+decision, these \emph{high-latency} networks resist strong global
+adversaries,
+but introduce too much lag for interactive tasks like web browsing,
 internet chat, or SSH connections.
 
 Tor belongs to the second category: \emph{low-latency} designs that
 attempt to anonymize interactive network traffic. These systems handle
-a variety of bidirectional protocols. They also provide more convenient
-mail delivery than the high-latency fire-and-forget anonymous email
-networks, because the remote mail server provides explicit delivery
-confirmation. But because these designs typically
+a variety of bidirectional protocols.
+% They also provide more convenient
+%mail delivery than the high-latency fire-and-forget anonymous email
+%networks, because the remote mail server provides explicit delivery
+%confirmation.
+But because these designs typically
 involve many packets that must be delivered quickly, it is
 difficult for them to prevent an attacker who can eavesdrop both ends of the
 communication from correlating the timing and volume
@@ -482,7 +486,7 @@
 talking to Bob if the timing and volume patterns of the traffic on the
 connection are distinct enough; active attackers can induce timing
 signatures on the traffic to \emph{force} distinct patterns. Tor
-does not address these \emph{traffic confirmation} attacks.
+does not yet address these \emph{traffic confirmation} attacks.
 Rather, we aim to prevent \emph{traffic
 analysis} attacks, where the adversary uses traffic patterns to learn
 which points in the network he should attack.
@@ -793,8 +797,8 @@
 SSH, is
 an open problem. Modifying or replacing the local nameserver
 can be invasive, brittle, and not portable. Forcing the resolver
-library to do its resolution via TCP rather than UDP is
-hard to do right, and also has portability problems. We could provide a
+library to do resolution via TCP rather than UDP is
+hard, and also has portability problems. We could provide a
 tool similar to \emph{dig} to perform a private lookup through the
 Tor network. Our current answer is to encourage the use of
 privacy-aware proxies like Privoxy wherever possible.
@@ -1370,7 +1374,7 @@
 \Section{Attacks and Defenses}
 \label{sec:attacks}
 
-% XXX In sec4 we should talk about bandwidth classes, which will
+% XXX In sec9 we should talk about bandwidth classes, which will
 %     enable us to accept a lot more ORs than if we continue to
 %     require 10mbit connections for all ORs. -RD
 
@@ -1380,21 +1384,18 @@
 
 \subsubsection*{Passive attacks}
 
-\emph{Observing user traffic patterns.} Observations of connection
-between a user and her first onion router will not reveal to whom
-the user is connecting or what information is being sent. It will
-reveal patterns of user traffic (both sent and received). Simple
-profiling of user connection patterns is not generally possible,
-however, because multiple application streams may be operating
-simultaneously or in series over a single circuit. Thus, further
-processing is necessary to discern even these usage patterns.
+\emph{Observing user traffic patterns.} Observing the connection
+from the user will not reveal her destination or data, but it will
+reveal traffic patterns (both sent and received). Profiling via user
+connection patterns is hampered because multiple application streams may
+be operating simultaneously or in series over a single circuit. Thus,
+further processing is necessary to discern even these usage patterns.
   
-\emph{Observing user content.} At the user end, content is
-encrypted; however, connections from the network to arbitrary
-websites may not be. Further, a responding website may itself be
-hostile. Filtering content is not a primary goal of
-Onion Routing; nonetheless, Tor can directly make use of Privoxy and
-related filtering services to anonymize application data streams.
+\emph{Observing user content.} While content at the user end is encrypted,
+connections to responders may not be (further, the responding website
+itself may be hostile). Filtering content is not a primary goal of Onion
+Routing; nonetheless, Tor can directly use Privoxy and related
+filtering services to anonymize application data streams.
 
 \emph{Option distinguishability.} Configuration options can be a
 source of distinguishable patterns. In general there is economic
@@ -1524,12 +1525,6 @@
 could possibly attract a disproportionately large amount of traffic
 by running an exit node with an unusually permissive exit policy.
 
-\emph{Compromise entire path.} Anyone compromising both
-endpoints of a circuit can confirm this with high probability. If
-the entire path is compromised, this becomes a certainty; however,
-the added benefit to the adversary of such an attack is small in
-relation to the difficulty.
-
 \emph{Run a hostile directory server.} Directory servers control
 admission to the network. However, because the network directory
 must be signed by a majority of servers, the threat of a single
@@ -1676,18 +1671,17 @@
 % There must be a better intro than this! -NM
 In addition to the open problems discussed in
 Section~\ref{subsec:non-goals}, many other questions remain to be
-solved by future research before we can be confident that we
-have built a secure low-latency anonymity service.
+solved by future research before we can be confident of our security.
 
 Many of these open issues are questions of balance.  For example,
 how often should users rotate to fresh circuits?  Too-frequent
-rotation is inefficient, expensive, and may lead to intersection attacks,
+rotation is inefficient, expensive, and may lead to intersection attacks
+and predecessor attacks \cite{wright03},
 but too-infrequent rotation
-makes the user's traffic linkable.   Instead of opening a fresh
-circuit; clients can also limit linkability by exiting from a middle point
-of the circuit, or by truncating and re-extending the circuit, but
+makes the user's traffic linkable.   Along with opening a fresh
+circuit, clients can also limit linkability by exiting from a middle point
+of the circuit, or by truncating and re-extending the circuit; but
 more analysis is needed to determine the proper trade-off.
-%[XXX mention predecessor attacks?]
 
 A similar question surrounds timing of directory operations:
 how often should directories be updated?  With too-infrequent
@@ -1696,7 +1690,6 @@
 
 %do different exit policies at different exit nodes trash anonymity sets,
 %or not mess with them much?
-%
 %% Why would they?  By routing traffic to certain nodes preferentially?
 
 %[XXX Choosing paths and path lengths: I'm not writing this bit till