move some stuff around in sections 1,2,3. Not done yet; still need to work on "Distributed Trust", "related work"

svn:r3571

doc/design-paper/challenges.tex

@@ -1,4 +1,6 @@
 \documentclass{llncs}
+% XXXX NM: Fold ``bandwidth and usability'' into ``Tor and filesharing'' --
+% ``bandwidth and file-sharing''.
 
 \usepackage{url}
 \usepackage{amsmath}
@@ -16,74 +18,71 @@
 
 \title{Challenges in deploying low-latency anonymity (DRAFT)}
 
-\author{Roger Dingledine and Nick Mathewson}
+%\author{Roger Dingledine and Nick Mathewson and }
-\institute{The Free Haven Project\\
+%\institute{The Free Haven Project\\
-\email{\{arma,nickm\}@freehaven.net}}
+%\email{\{arma,nickm\}@freehaven.net}}
+\author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
+Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
+Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
 
 \maketitle
 \pagestyle{empty}
 
 \begin{abstract}
-  
+  There are many unexpected or unexpectedly difficult obstacles to
-  We describe our experiences with deploying Tor, a low-latency
+  deploying anonymous communications.  Drawing on our experiences deploying
-  anonymous general purpose communication system that has been funded
+  Tor (the next-generation onion routing network), we describe social
-  by the U.S.~Navy, DARPA, and the Electronic Frontier Foundation. The
+  challenges and technical issues that must be faced
-  basic Tor design supports most applications that run over TCP (those
+  in building, deploying, and sustaining a scalable, distributed, low-latency
-  that are SOCKS compliant).
+  anonymity network.
-
-%Because of its simplified threat model, Tor does not aim to defend
-%against many of the attacks in the literature.
-
-We describe both policy issues that have come up from operating the
-network and technical challenges to building a more sustainable and
-scalable network.
-
 \end{abstract}
 
 \section{Introduction}
-
+% Your network is not practical unless it is sustainable and distributed.
-Anonymous communication is full of surprises. In this paper we will
+Anonymous communication is full of surprises.  This paper discusses some
-tell you about some of them. We will describe the challenges arising
+unexpected challenges arising from our experiences deploying Tor, a
-from our experiences with deploying, Tor, a low-latency anonymous general
+low-latency general-purpose anonymous communication system.  We will discuss
-purpose communication system. We will discuss some of the difficulties
+some of the difficulties we have experienced and how we have met them (or how
-we have experienced, how we have met them or, when we have some idea,
+we plan to meet them, if we know).  We will also discuss some less
-how we plan to meet them. We will also discuss some tough open
+troublesome open problems that we must nevertheless eventually address.
-problems that have not given us any trouble in our current deployment.
+%We will describe both those future challenges that we intend to explore and
-We will describe both those future challenges that we intend to explore and
+%those that we have decided not to explore and why.
-those that we have decided not to explore and why.
+
-
+Tor is an overlay network for anonymizing TCP streams over the
-Tor is an overlay network, designed
+Internet~\cite{tor-design}.  It addresses limitations in earlier Onion
-to be practical and usable, for protecting TCP streams over the
+Routing designs~\cite{or-ih96,or-jsac98,or-discex00,or-pet00} by adding
-Internet~\cite{tor-design}. We have been operating a publicly deployed
+perfect forward secrecy, congestion control, directory servers, integrity
-Tor network since October 2003 that has grown to over a hundred volunteer
+checking, configurable exit policies, and location-hidden services using
-nodes and sometimes as much as 80 megabits of average traffic per second.
+rendezvous points.  Tor works on the real-world Internet, requires no special
-
+privileges or kernel modifications, requires little synchronization or
-Tor has a weaker threat model than many anonymity designs in the
+coordination between nodes, and provides a reasonable tradeoff between
-literature, because our foremost goal is to deploy a
+anonymity, usability, and efficiency.
-practical and useful network for interactive (low-latency) communications.
+
-Subject to this restriction, we try to
+We first publicly deployed a Tor network in October 2003; since then it has
-provide as much anonymity as we can. In particular, because we
+grown to over a hundred volunteer servers and as much as 80 megabits of
-support interactive communications without impractically expensive padding,
+average traffic per second.  Tor's research strategy has focused on deploying
-we fall prey to a variety
+a network to as many users as possible; thus, we have resisted designs that
-of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
+would compromise deployability by imposing high resource demands on server
-end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
+operators, and designs that would compromise usability by imposing
-
+unacceptable restrictions on which applications we support.  Although this
-Users are safe so long as adversaries are unable to
+strategy has
-observe connections as they both enter and leave the Tor network.
+its drawbacks (including a weakened threat model, as discussed below), it has
-Therefore, Tor's defense lies in having a diverse enough set of servers
+made it possible for Tor to serve many thousands of users, and attract
-that most real-world
+research funding from organizations so diverse as ONR and DARPA
-adversaries are unlikely to be in the right places to attack users.
+(for use in securing sensitive communications), and the Electronic Frontier
-Specifically,
+Foundation (for maintaining civil liberties of ordinary citizens online).
-Tor aims to resist observers and insiders by distributing each transaction
+
-over several nodes in the network.  This ``distributed trust'' approach
+While the Tor design paper~\cite{tor-design} gives an overall view of Tor's
-means the Tor network can be safely operated and used by a wide variety
+design and goals, this paper describes some policy, social, and technical
-of mutually distrustful users, providing more sustainability and security
+issues that we face as we continue deployment.
-than some previous attempts at anonymizing networks.
+Rather than trying to provide complete solutions to every problem here, we
-The Tor network has a broad range of users, including ordinary citizens
+lay out the assumptions and constraints that we have observed while
-concerned about their privacy, corporations
+deploying Tor in the wild.  In doing so, we aim to create a research agenda
-who don't want to reveal information to their competitors, and law
+for others to help in addressing these issues.  We believe that the issues
-enforcement and government intelligence agencies who need
+described here will be of general interest to projects attempting to build
-to do operations on the Internet without being noticed.
+and deploy practical, useable anonymity networks in the wild.
+
+% ----------------
 
 Tor research and development has been funded by the U.S.~Navy and DARPA
 for use in securing government
@@ -97,33 +96,15 @@ their popular Java Anon Proxy anonymizing client. This wide variety of
 interests helps maintain both the stability and the security of the
 network.
 
-The ideal Tor network would be practical, useful and and anonymous. When
+
-trade-offs arise between these properties, Tor's research strategy has been
+%While the Tor design paper~\cite{tor-design} gives an overall view its
-to insist on remaining useful enough to attract many users,
+%design and goals,
-and practical enough to support them.  Subject to these
+%this paper describes the policy and technical issues that Tor faces as
-constraints, we aim to maximize anonymity.  This is not the only possible
+%we continue deployment. Rather than trying to provide complete solutions
-direction in anonymity research: designs exist that provide more anonymity
+%to every problem here, we lay out the assumptions and constraints
-than Tor at the expense of significantly increased resource requirements, or
+%that we have observed through deploying Tor in the wild. In doing so, we
-decreased flexibility in application support (typically because of increased
+%aim to create a research agenda for others to
-latency).  Such research does not typically abandon aspirations towards
+%help in addressing these issues.
-deployability or utility, but instead tries to maximize deployability and
-utility subject to a certain degree of inherent anonymity (inherent because
-usability and practicality affect usage which affects the actual anonymity
-provided by the network \cite{back01,econymics}). 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 the Tor design paper~\cite{tor-design} gives an overall view its
-design and goals,
-this paper describes the policy and technical issues that Tor faces as
-we continue deployment. Rather than trying to provide complete solutions
-to every problem here, we lay out the assumptions and constraints
-that we have observed through deploying Tor in the wild. In doing so, we
-aim to create a research agenda for others to
-help in addressing these issues.
 % Section~\ref{sec:what-is-tor} gives an
 %overview of the Tor
 %design and ours goals. Sections~\ref{sec:crossroads-policy}
@@ -133,15 +114,18 @@ help in addressing these issues.
 %from a practical useful network to a practical useful anonymous network.
 
 %\section{What Is Tor}
-\section{Distributed trust: safety in numbers}
+\section{Background}
+Here we give a basic overview of the Tor design and its properties, and
+compare Tor to other low-latency anonymity designs.
+
+\subsection{Tor, threat models, and distributed trust}
 \label{sec:what-is-tor}
 
 %Here we give a basic overview of the Tor design and its properties. For
 %details on the design, assumptions, and security arguments, we refer
 %the reader to the Tor design paper~\cite{tor-design}.
 
-% XXX this section needs to mention that we have exit policies.
+\subsubsection{How Tor works}
-
 Tor provides \emph{forward privacy}, so that users can connect to
 Internet sites without revealing their logical or physical locations
 to those sites or to observers.  It also provides \emph{location-hidden
@@ -150,25 +134,26 @@ giving adversaries an effective vector for physical or online attacks.
 The design provides these protections even when a portion of its own
 infrastructure is controlled by an adversary.
 
-To create a private network pathway with Tor, the client
+To create a private network pathway with Tor, the client software
 incrementally builds a \emph{circuit} of encrypted connections through
 servers on the network. The circuit is extended one hop at a time, and
 each server along the way knows only which server gave it data and which
 server it is giving data to. No individual server ever knows the complete
 path that a data packet has taken. The client negotiates a separate set
-of encryption keys for each hop along the circuit to ensure that each
+of encryption keys for each hop along the circuit.% to ensure that each
-hop can't trace these connections as they pass through.
+%hop can't trace these connections as they pass through.
 Because each server sees no more than one hop in the
 circuit, neither an eavesdropper nor a compromised server can use traffic
 analysis to link the connection's source and destination.
-For efficiency, the Tor software uses the same circuit for connections
+For efficiency, the Tor software uses the same circuit for all the TCP
-that happen within the same short period. Later requests are given a new
+connections that happen within the same short period.
+Later requests use a new
 circuit, to prevent long-term linkability between different actions by
 a single user.
 
 Tor also makes it possible for users to hide their locations while
 offering various kinds of services, such as web publishing or an instant
-messaging server. Using Tor ``rendezvous points'', other Tor users can
+messaging server. Using ``rendezvous points'', other Tor users can
 connect to these hidden services, each without knowing the other's network
 identity.
 
@@ -176,99 +161,62 @@ 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 connections via
+IP packets; it only anonymizes TCP streams and DNS request, and only supports
-SOCKS (see Section~\ref{subsec:tcp-vs-ip}).
+connections via 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
-Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
-gain the highest degrees of anonymity at the expense of introducing highly
-variable delays, thus making them unsuitable for applications such as web
-browsing.  Commercial single-hop
-proxies~\cite{anonymizer} present a single point of failure, where
-a single compromise can expose all users' traffic, and a single-point
-eavesdropper can perform traffic analysis on the entire network.
-Also, their proprietary implementations place any infrastucture that
-depends on these single-hop solutions at the mercy of their providers'
-financial health as well as network security.
 
-No organization can achieve this security on its own.  If a single
+Most servers operators do not want to allow arbitary TCP connections to leave
-corporation or government agency were to build a private network to
+their servers.  To address this, Tor provides \emph{exit policies} so that
-protect its operations, any connections entering or leaving that network
+each server can block the IP addresses and ports it is unwilling to allow.
-would be obviously linkable to the controlling organization.  The members
+Servers advertise their exit policies to the directory servers, so that
-and operations of that agency would be easier, not harder, to distinguish.
+client can tell which servers will support their connections.
-
-Instead, to protect our networks from traffic analysis, we must
-collaboratively blend the traffic from many organizations and private
-citizens, so that an eavesdropper can't tell which users are which,
-and who is looking for what information.  By bringing more users onto
-the network, all users become more secure~\cite{econymics}.
-
-Naturally, organizations will not want to depend on others for their
-security.  If most participating providers are reliable, Tor tolerates
-some hostile infiltration of the network.  For maximum protection,
-the Tor design includes an enclave approach that lets data be encrypted
-(and authenticated) end-to-end, so high-sensitivity users can be sure it
-hasn't been read or modified.  This even works for Internet services that
-don't have built-in encryption and authentication, such as unencrypted
-HTTP or chat, and it requires no modification of those services.
 
 As of January 2005, the Tor network has grown to around a hundred servers
 on four continents, with a total capacity exceeding 1Gbit/s. Appendix A
 shows a graph of the number of working servers over time, as well as a
-graph of the number of bytes being handled by the network over time. At
+vgraph of the number of bytes being handled by the network over time. At
 this point the network is sufficiently diverse for further development
 and testing; but of course we always encourage and welcome new servers
 to join the network.
 
-%Tor doesn't try to provide steg (but see Section~\ref{subsec:china}), or
+\subsubsection{Threat models and design philosophy}
-%the other non-goals listed in tor-design.
+The ideal Tor network would be practical, useful and and anonymous. When
-
+trade-offs arise between these properties, Tor's research strategy has been
-Tor is not the only anonymity system that aims to be practical and useful.
+to insist on remaining useful enough to attract many users,
-Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
+and practical enough to support them.  Only subject to these
-open proxies around the Internet, can provide good
+constraints do we aim to maximize
-performance and some security against a weaker attacker. The Java
+anonymity.\footnote{This is not the only possible
-Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
+direction in anonymity research: designs exist that provide more anonymity
-handles web browsing rather than arbitrary TCP\@.
+than Tor at the expense of significantly increased resource requirements, or
-%Some peer-to-peer file-sharing overlay networks such as
+decreased flexibility in application support (typically because of increased
-%Freenet~\cite{freenet} and Mute~\cite{mute}
+latency).  Such research does not typically abandon aspirations towards
-Zero-Knowledge Systems' commercial Freedom
+deployability or utility, but instead tries to maximize deployability and
-network~\cite{freedom21-security} was even more flexible than Tor in
+utility subject to a certain degree of inherent anonymity (inherent because
-that it could transport arbitrary IP packets, and it also supported
+usability and practicality affect usage which affects the actual anonymity
-pseudonymous access rather than just anonymous access; but it had
+provided by the network \cite{back01,econymics}). We believe that these
-a different approach to sustainability (collecting money from users
+approaches can be promising and useful, but that by focusing on deploying a
-and paying ISPs to run servers), and has shut down due to financial
+usable system in the wild, Tor helps us experiment with the actual parameters
-load.  Finally, more scalable designs like Tarzan~\cite{tarzan:ccs02} and
+of what makes a system ``practical'' for volunteer operators and ``useful''
-MorphMix~\cite{morphmix:fc04} have been proposed in the literature, but
+for home users, and helps illuminate undernoticed issues which any deployed
-have not yet been fielded. We direct the interested reader to Section
+volunteer anonymity network will need to address.}
-2 of~\cite{tor-design} for a more indepth review of related work.
+Because of this strategy, Tor has a weaker threat model than many anonymity
-
+designs in the literature.   In particular, because we
-%six-four. crowds. i2p.
+support interactive communications without impractically expensive padding,
+we fall prey to a variety
+of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
+end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
 
-have a serious discussion of morphmix's assumptions, since they would
-seem to be the direct competition. in fact tor is a flexible architecture
-that would encompass morphmix, and they're nearly identical except for
-path selection and node discovery. and the trust system morphmix has
-seems overkill (and/or insecure) based on the threat model we've picked.
-% this para should probably move to the scalability / directory system. -RD
 
-\section{Threat model}
+Tor does not attempt to defend against a global observer.  In general, an
-\label{sec:threat-model}
+attacker who can observe both ends of a connection through the Tor network
-
+can correlate the timing and volume of data on that connection as it enters
-Tor does not attempt to defend against a global observer.  Any adversary who
+and leaves the network, and so link a user to her chosen communication
-can see a user's connection to the Tor network, and who can see the
+parties.  Known solutions to this attack would seem to require introducing a
-corresponding connection as it exits the Tor network, can use timing
+prohibitive degree of traffic padding between the user and the network, or
-correlation to confirm the user's chosen
+introducing an unacceptable degree of latency (but see Section
-communication partners.  Defeating this attack would seem to require
+\ref{subsec:mid-latency}).  Also, it is not clear that these methods would
-introducing a prohibitive degree of traffic padding between the user and the
+work at all against a minimally active adversary that can introduce timing
-network, or introducing an unacceptable degree of latency (but see
+patterns or additional traffic.  Thus, Tor only attempts to defend against
-Section \ref{subsec:mid-latency}).
+external observers who cannot observe both sides of a user's connection.
-And, it is not clear that padding works at all if we assume a
-minimally active adversary that modifies the timing of packets
-to or from the user by sending network traffic of his own. Thus, Tor
-only attempts to defend against
-external observers who cannot 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
@@ -301,7 +249,7 @@ complicating factors:
 % not? -nm
 % Sure. In fact, better off, since they seem to scale more easily. -rd
 
-% the below paragraph should probably move later, and merge with
+% XXXX the below paragraph should probably move later, and merge with
 % other discussions of attack-tor-oak5.
 In practice Tor's threat model is based entirely on the goal of
 dispersal and diversity. Murdoch and Danezis describe an attack
@@ -327,20 +275,102 @@ it identifies endpoints when they're also nodes in the Tor network:
 see Section~\ref{subsec:helper-nodes} for discussion of some ways to
 address this issue.
 
-
+See \ref{subsec:routing-zones} for discussion of larger
-see \ref{subsec:routing-zones} for discussion of larger
 adversaries and our dispersal goals.
 
-[this section will get written once the rest of the paper is farther along]
+\subsubsection{Distributed trust}
+Tor's defense lies in having a diverse enough set of servers
+to prevent most real-world
+adversaries from being in the right places to attack users.
+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 some previous attempts at anonymizing networks.
+The Tor network has a broad range of users, including ordinary citizens
+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.
+
+No organization can achieve this security on its own.  If a single
+corporation or government agency were to build a private network to
+protect its operations, any connections entering or leaving that network
+would be obviously linkable to the controlling organization.  The members
+and operations of that agency would be easier, not harder, to distinguish.
+
+Instead, to protect our networks from traffic analysis, we must
+collaboratively blend the traffic from many organizations and private
+citizens, so that an eavesdropper can't tell which users are which,
+and who is looking for what information.  By bringing more users onto
+the network, all users become more secure~\cite{econymics}.
+
+Naturally, organizations will not want to depend on others for their
+security.  If most participating providers are reliable, Tor tolerates
+some hostile infiltration of the network.  For maximum protection,
+the Tor design includes an enclave approach that lets data be encrypted
+(and authenticated) end-to-end, so high-sensitivity users can be sure it
+hasn't been read or modified.  This even works for Internet services that
+don't have built-in encryption and authentication, such as unencrypted
+HTTP or chat, and it requires no modification of those services.
+
+%Tor doesn't try to provide steg (but see Section~\ref{subsec:china}), or
+%the other non-goals listed in tor-design.
+
+\subsection{Related work}
+Tor is not the only anonymity system that aims to be practical and useful.
+Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
+open proxies around the Internet, can provide good
+performance and some security against a weaker attacker. The Java
+Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
+handles web browsing rather than arbitrary TCP\@.
+%Some peer-to-peer file-sharing overlay networks such as
+%Freenet~\cite{freenet} and Mute~\cite{mute}
+Zero-Knowledge Systems' commercial Freedom
+network~\cite{freedom21-security} was even more flexible than Tor in
+that it could transport arbitrary IP packets, and it also supported
+pseudonymous access rather than just anonymous access; but it had
+a different approach to sustainability (collecting money from users
+and paying ISPs to run servers), and has shut down due to financial
+load.  Finally, more scalable designs like Tarzan~\cite{tarzan:ccs02} and
+MorphMix~\cite{morphmix:fc04} have been proposed in the literature, but
+have not yet been fielded. We direct the interested reader to Section
+2 of~\cite{tor-design} for a more in-depth review of related work.
+
+Tor differs from other deployed systems for traffic analysis resistance
+in its security and flexibility.  Mix networks such as
+Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
+gain the highest degrees of anonymity at the expense of introducing highly
+variable delays, thus making them unsuitable for applications such as web
+browsing.  Commercial single-hop
+proxies~\cite{anonymizer} present a single point of failure, where
+a single compromise can expose all users' traffic, and a single-point
+eavesdropper can perform traffic analysis on the entire network.
+Also, their proprietary implementations place any infrastucture that
+depends on these single-hop solutions at the mercy of their providers'
+financial health as well as network security.
+
+%XXXX six-four. crowds. i2p.
+
+%XXXX
+have a serious discussion of morphmix's assumptions, since they would
+seem to be the direct competition. in fact tor is a flexible architecture
+that would encompass morphmix, and they're nearly identical except for
+path selection and node discovery. and the trust system morphmix has
+seems overkill (and/or insecure) based on the threat model we've picked.
+% this para should probably move to the scalability / directory system. -RD
+
 
 \section{Crossroads: Policy issues}
 \label{sec:crossroads-policy}
 
-Many of the issues the Tor project needs to address are not just a
+Many of the issues the Tor project needs to address extend beyond
-matter of system design or technology development. In particular, the
+system design and technology development. In particular, the
 Tor project's \emph{image} with respect to its users and the rest of
 the Internet impacts the security it can provide.
+% No image, no sustainability -NM
 
+% Fold this into next subsec.
 As an example to motivate this section, some U.S.~Department of Energy
 penetration testing engineers are tasked with compromising DoE computers
 from the outside. They only have a limited number of ISPs from which to
@@ -357,6 +387,7 @@ With this image issue in mind, this section discusses the Tor user base and
 Tor's interaction with other services on the Internet.
 
 \subsection{Image and security}
+% Communicating security? - NM
 
 A growing field of papers argue that usability for anonymity systems
 contributes directly to their security, because how usable the system
@@ -423,6 +454,7 @@ matter as much as we'd like, it still helps to have some other users
 who use the network. We investigate this issue in the next section.
 
 \subsection{Reputability}
+% Maintaining image of social value?  Social value?  -NM
 
 Another factor impacting the network's security is its reputability:
 the perception of its social value based on its current user base. If Alice is
@@ -496,9 +528,11 @@ Still, anonymity and privacy incentives do remain for server operators:
   of ``deniability'' for traffic that originates at that exit node.  For
   example, it is likely in practice that HTTP requests from a Tor server's IP
   will be assumed to be from the Tor network.
-\item Local Tor entry and exit servers allow users on a network to run in an
+XXXX clarify.
-  `enclave' configuration.  [XXXX need to resolve this. They would do this
+\item Maintain the sustainability of the network. XXX sentencize
-   for E2E encryption + auth?]
+%\item Local Tor entry and exit servers allow users on a network to run in an
+%  `enclave' configuration.  [XXXX need to resolve this. They would do this
+%   for E2E encryption + auth?]
 \end{tightlist}
 
 First, we try to make the costs of running a Tor server easily minimized.
@@ -542,6 +576,9 @@ over anonymity tend to leave the system, thus freeing capacity until the
 remaining users on the network are exactly those willing to use that capacity
 there is.
 
+XXX But is it the right equilibirum?  And if it's the wrong one, we lose
+XXX users.  And if we lose the wrong users, servers won't want to help.
+
 XXX what if the file-sharers are more persistent than the journalists?
 
 \subsection{Tor and file-sharing}
@@ -582,7 +619,7 @@ ports.
 For the moment, it seems that Tor's bandwidth issues have rendered it
 unattractive for bulk file-sharing traffic; this may continue to be so in the
 future.  Nevertheless, Tor will likely remain attractive for limited use in
-filesharing protocols that have separate control and data channels.
+  filesharing protocols that have separate control and data channels.
 
 [xxxx We should say more -- but what?  That we'll see a similar
   equilibriating effect as with bandwidth, where sensitive ops switch to
@@ -594,6 +631,11 @@ in practice, plausible deniability is hypothetical and doesn't seem very
 convincing. if ISPs find the activity antisocial, they don't care *why*
 your computer is doing that behavior.
 
+XXXX deliberately give priority to quiet circuits?
+XXXX or non file-sharing ports??
+XXXX Point is not to beat them off the network, but to keep them from
+XXXX    hogging the network.
+
 \subsection{Tor and blacklists}
 
 It was long expected that, alongside Tor's legitimate users, it would also
@@ -638,6 +680,9 @@ from these networks even though Tor does not allow SMTP at all.)
 [****Since this is stupid and we oppose it, shouldn't we name names here -pfs]
 [XXX also, they're making \emph{middleman nodes leave} because they're caught
  up in the standoff!]
+[XXX Mention: it's not dumb, it's strategic!]
+[XXX Mention: for some servops, any blacklist is a blacklist too many,
+  because it is risky.  (Guy lives in apt with one IP.)]
 
 Problems of abuse occur mainly with services such as IRC networks and
 Wikipedia, which rely on IP blocking to ban abusive users.  While at first
@@ -693,9 +738,13 @@ workable alternative.
 %by implementing the Morphmix-specific node discovery and path selection
 %pieces.
 
+[XXX Mention correct DNS-RBL implementation. -NM]
+
 \section{Crossroads: Design choices}
 \label{sec:crossroads-design}
 
+[XXX sentence here.]
+
 \subsection{Transporting the stream vs transporting the packets}
 \label{subsec:stream-vs-packet}
 \label{subsec:tcp-vs-ip}
@@ -753,6 +802,7 @@ would be good to investigate each of these items in further depth and to
 understand which are actual roadblocks and which are easier to resolve
 than we think. We certainly wouldn't mind if Tor one day is able to
 transport a greater variety of protocols.
+[XXX clarify our actual attitude here. -NM]
 
 \subsection{Mid-latency}
 \label{subsec:mid-latency}