Add initial background mumblings; more work tomorrow

svn:r586

1 files changed, 94 insertions, 4 deletions

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 758e24f96d..7805c46a2b 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -167,13 +167,78 @@ open problems.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\Section{Threat model and background}
+\Section{Background and threat model}
 \label{sec:background}
 
+\SubSection{Related work}
+\label{sec:related-work}
+Modern anonymity designs date to Chaum's Mix-Net\cite{chaum-mix} design of
+1981.  Chaum proposed hiding sender-recipient connections by wrapping
+messages in several layers of public key cryptography, and relaying them
+through a path composed of Mix servers.  Mix servers in turn decrypt, delay,
+and re-order messages, before relay them along the path towards their
+destinations.
+
+Subsequent relay-based anonymity designs have diverged in two principal
+directions.  Some have, such as Babel\cite{babel}, Mixmaster\cite{mixmaster},
+and Mixminion\cite{minion-design}, attempt to maximize anonymity at the cost
+of introducing comparatively large and variable latencies.  Because of this
+decision, such \emph{high-latency} networks are well-suited for anonymous
+email, but introduce too much lag for interactive tasks such as web browsing,
+internet chat, or SSH connections.
+
+Tor belongs to the second category: \emph{low-latency} designs that attempt
+to anonymize interactive network traffic.  Because such traffic tends to
+involve a relatively large numbers of packets, it is difficult to prevent an
+attacker who can eavesdrop entry and exit points from correlating packets
+entering the anonymity network with packets leaving it. Although some
+work has been done to frustrate these attacks, they still...  
+[XXX go on to explain how the design choices implied in low-latency result in
+significantly different designs.]
+
+The simplest low-latency designs are single-hop proxies such as the
+Anonymizer, wherein a single trusted server removes identifying users' data
+before relaying it.  These designs are easy to analyze, but require end-users
+to trust the anonymizing proxy.
+
+More complex are distributed-trust, channel-based anonymizing systems.  In
+these designs, a user establishes one or more medium-term bidirectional
+end-to-end tunnels to exit servers, and uses those tunnels to deliver a
+number of low-latency packets to and from one or more destinations per
+tunnel.  Establishing tunnels is comparatively expensive and typically
+requires public-key cryptography, whereas relaying packets along a tunnel is
+comparatively inexpensive.  Because a tunnel crosses several servers, no
+single server can learn the user's communication partners.
+[XXX give examples.]  
+[XXX Everybody I know except Crowds and gnunet is in this category.  Am I
+right?]
+
+[XXX Should we add a paragraph dividing servers by all-at-once approach to
+  tunnel-building (OR1,Freedom1) versus piecemeal approach
+  (OR2,Anonnet?,Freedom2) ?]
+
+Distributed-trust anonymizing systems differ in how they prevent attackers
+from controlling too many servers and thus compromising too many user paths.
+Some protocols rely on a centrally maintained set of well-known anonymizing
+servers.  Others (such as Tarzan and MorphMix) allow unknown users to run
+servers, while using a limited resource (DHT space for Tarzan; IP space for
+MorphMix) to prevent an attacker from owning too much of the network.
+[XXX what else?  What does (say) crowds do?]
+
+Channel-based anonymizing systems also differ in their use of dummy traffic.
+[XXX]
+
+Finally, several systems provide low-latency anonymity without channel-based
+communication.  Crowds and [XXX] provide anonymity for HTTP requests; [...]
+
+[XXX Mention error recovery?]
+
+
 anonymizer
 pipenet
-freedom
-onion routing
+freedom v1
+freedom v2
+onion routing v1
 isdn-mixes
 crowds
 real-time mixes, web mixes
@@ -184,18 +249,43 @@ gnunet
 rewebbers
 tarzan
 herbivore
+hordes
+cebolla (?)
 
-\SubSection{Known attacks against low-latency anonymity systems}
+[XXX Close by mentioning where Tor fits.]
 
+\SubSection{Our threat model}
+\label{subsec:threat-model}
 
+\SubSection{Known attacks against low-latency anonymity systems}
+\label{subsec:known-attacks}
 
 We discuss each of these attacks in more detail below, along with the
 aspects of the Tor design that provide defense. We provide a summary
 of the attacks and our defenses against them in Section \ref{sec:attacks}.
 
+Passive attacks:
+simple observation,
+timing correlation,
+size correlation,
+option distinguishability,
+
+Active attacks:
+key compromise,
+iterated subpoena,
+run recipient,
+run a hostile node,
+compromise entire path,
+selectively DOS servers,
+introduce timing into messages,
+directory attacks,
+tagging attacks
+
 \Section{Design goals and assumptions}
 \label{sec:assumptions}
 
+[XXX Perhaps the threat model belongs here.]
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \Section{The Tor Design}