Commit notes from Friday mtg with arma.

svn:r676

1 files changed, 46 insertions, 20 deletions

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 9b7bb1227..756b43287 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -102,6 +102,8 @@ each successive hop in the circuit. Onion replay detection is no longer
 necessary, and the process of building circuits is more reliable, since
 the initiator knows when a hop fails and can then try extending to a new node.
 
+% Perhaps mention that not all of these are things that we invented. -NM
+
 \item \textbf{Separation of protocol cleaning from anonymity:}
 The original Onion Routing design required a separate ``application
 proxy'' for each
@@ -145,6 +147,9 @@ use is not practical or economical; and even full link padding is still
 vulnerable to active attacks \cite{defensive-dropping}.
 %[An upcoming FC04 paper. I'll add a cite when it's out. -RD]
 
+%Say that: although some less resource-heavy traffic shaping approaches may 
+%help resist certain attacks, we aren't getting on the bandwagon yet?  -NM.
+
 \item \textbf{Leaky-pipe circuit topology:} Through in-band
   signalling within the
   circuit, Tor initiators can direct traffic to nodes partway down the
@@ -249,10 +254,12 @@ principal directions.  Some have attempted to maximize anonymity at
 the cost of introducing comparatively large and variable latencies,
 for example, Babel\cite{babel}, Mixmaster\cite{mixmaster-spec}, and
 Mixminion\cite{minion-design}.  Because of this
-decision, such \emph{high-latency} networks are well-suited for anonymous
+trade-off, 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.
 
+% Parts of this graf belongs later in expository order.  Some of the
+% sentences seem superficially unrelated. 
 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
@@ -272,8 +279,8 @@ been run for many years (the Java Anon Proxy, aka Web MIXes,
 \cite{web-mix}).
 
 Another low latency design that was proposed independently and at
-about the same time as Onion Routing was PipeNet \cite{pipenet}.
-This provided anonymity protections that were stronger than Onion Routing's,
+about the same time as the original Onion Routing was PipeNet \cite{pipenet}.
+It provided anonymity protections that were stronger than Onion Routing's,
 but at the cost of allowing a single user to shut down the network simply
 by not sending. It was also never implemented or formally published.
 
@@ -291,10 +298,11 @@ 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.
 
-Systems such as earlier versions of Freedom and Onion Routing
-build the anonymous channel all at once (using an onion). Later
-designs of Freedom and Onion Routing as described herein build
-the channel in stages as does AnonNet
+%[Ouch: We haven't said what an onion is yet, but we use the word here! -NM]
+Systems such as earlier versions of Freedom and the original Onion Routing
+build the anonymous channel all at once (using an onion). 
+Later designs of Freedom and Tor as described herein build
+the channel in stages, as does AnonNet
 \cite{anonnet}. Amongst other things, this makes perfect forward
 secrecy feasible.
 
@@ -322,7 +330,7 @@ recipients.
 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.  Current Tor design falls into this category.
+servers.  The current Tor design falls into this category.
 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.
@@ -371,7 +379,7 @@ cebolla\\
 
 
 \subsection{Goals}
-% Are these really our goals? ;) -NM
+% Reformat this section like ``Adversary Model'' is formatted. -NM
 Like other low-latency anonymity designs, Tor seeks to frustrate
 attackers from linking communication partners, or from linking
 multiple communications to or from a single point.  Within this
@@ -392,7 +400,9 @@ Second, the system must be {\bf usable}.  A hard-to-use system has
 fewer users --- and because anonymity systems hide users among users, a
 system with fewer users provides less anonymity.  Thus, usability is
 not only a convenience, but is a security requirement for anonymity
-systems.
+systems.  In order to be usable, Tor should with most of a
+user's unmodified aplication; shouldn't introduce prohibitive delays; and 
+[XXX what else?].
 
 Third, the protocol must be {\bf extensible}, so that it can serve as
 a test-bed for future research in low-latency anonymity systems.
@@ -401,29 +411,29 @@ a danger that differing choices of extensions will render users
 distinguishable.  Thus, implementations should not permit different
 protocol extensions to coexist in a single deployed network.)
 
+% We should mention that there's a specification someplace: the spec makes us 
+% easier to extend too. -NM
+
 The protocol's design and security parameters must be {\bf
 conservative}.  Additional features impose implementation and
 complexity costs. [XXX Say that we don't want to try to come up with
 speculative solutions to problems we don't KNOW how to solve? -NM]
 
-[XXX mention something about robustness?  But we really aren't that
-  robust.  We just assume that tunneled protocols tolerate connection
-  loss. -NM]
-
 \subsection{Non-goals}
 In favoring conservative, deployable designs, we have explicitly
 deferred a number of goals --- not because they are not desirable in
-anonymity systems --- but because solving them is either solved
+anonymity systems --- but because they are either solved
 elsewhere, or an area of active research without a generally accepted
 solution.
 
 Unlike Tarzan or Morphmix, Tor does not attempt to scale to completely
 decentralized peer-to-peer environments with thousands of short-lived
-servers. 
+servers, many of which may be controlled by an adversary.
 
 Tor does not claim to provide a definitive solution to end-to-end
 timing or intersection attacks for users who do not run their own
 Onion Routers.
+% Mention would-be approaches. -NM
 % Does that mean we do claim to solve intersection attack for
 % the enclave-firewall model? -RD
 
@@ -497,7 +507,7 @@ The basic adversary components we consider are:
 %  for later. -PS
 
   
-\item[Compromised Tor-node:] can arbitrarily manipulate the
+\item{Hostile Tor node:] can arbitrarily manipulate the
   connections under its control, as well as creating new connections
   (that pass through itself).
 \end{description}
@@ -543,6 +553,7 @@ line refers to the immediately following SubSection.-PS]
 
 \SubSection{Known attacks against low-latency anonymity systems}
 \label{subsec:known-attacks}
+% Should be merged into ``Threat model'' and reiterated in Attacks. -NM
 
 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
@@ -563,10 +574,13 @@ compromise entire path,
 selectively DOS servers,
 introduce timing into messages,
 directory attacks,
-tagging attacks
+tagging attacks,
+smear attacks,
+entrapment attacks
 
 
 \SubSection{Assumptions}
+% Should be merged into ``Threat model''.
 
 For purposes of this paper, we assume all directory servers are honest
 % No longer true, see subsec:dirservers below -RD
@@ -763,11 +777,15 @@ addresses and ports the router will permit stream connections. On one end
 of the spectrum are \emph{open exit} nodes that will connect anywhere;
 on the other end are \emph{middleman} nodes that only relay traffic to
 other Tor nodes, and \emph{private exit} nodes that only connect locally
-or to addresses internal to that node's organization. This private exit
+or to addresses internal to that node's organization. 
+This private exit
 node configuration is more secure for clients --- the adversary cannot
 see plaintext traffic leaving the network (e.g. to a webserver), so he
 is less sure of Alice's destination. More generally, nodes can require
 a variety of forms of traffic authentication \cite{onion-discex00}.
+Most onnion routers will function as \emph{limited exits} that permit
+connections to the world at large, but restrict access to certain abuse-prone
+addresses and services.
 
 Tor offers more reliability than the high-latency fire-and-forget
 anonymous email networks, because the sender opens a TCP stream
@@ -795,6 +813,7 @@ even occurs to people that it wasn't you.
 
 Preventing abuse of open exit nodes is an unsolved problem. Princeton's
 CoDeeN project \cite{darkside} gives us a glimpse of what we're in for.
+% This is more speculative than a description of our design. 
 
 but their solutions, which mainly involve rate limiting and blacklisting
 nodes which do bad things, don't translate directly to Tor. Rate limiting
@@ -845,7 +864,7 @@ in-band network status updates: each router flooded a signed statement
 to its neighbors, which propagated it onward. But anonymizing networks
 have different security goals than typical link-state routing protocols.
 For example, we worry more about delays (accidental or intentional)
-which cause different parts of the network to have different pictures
+that can cause different parts of the network to have different pictures
 of link-state and topology. We also worry about attacks to deceive a
 client about the router membership list, topology, or current network
 state. Such \emph{partitioning attacks} on client knowledge help an
@@ -925,6 +944,7 @@ all the other onion routers (or even elsewhere). Thus directory servers
 are not a performance bottleneck when we have many users, and also they
 won't aid traffic analysis by forcing clients to periodically announce
 their existence to any central point.
+% Mention Hydra as an example of non-clique topologies. -NM, from RD
 
 \Section{Rendezvous points: location privacy}
 \label{sec:rendezvous}
@@ -1162,6 +1182,11 @@ it could give you a bad IP that sends you somewhere else.
 \item foo
 \end{itemize}
 
+\item \textbf{Attacks against rendezvous points}
+\begin{itemize}
+\item foo
+\end{itemize}
+
 \end{enumerate}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1208,6 +1233,7 @@ gain experience in deploying an anonymizing overlay network, and learn
 from having actual users. We are now at the point where we can start
 deploying a wider network. We will see what happens!
 % ok, so that's hokey. fix it. -RD
+\item \emph{Further specification review:} Foo.
 \end{itemize}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%