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}
-\institute{The Free Haven Project\\
-\email{\{arma,nickm\}@freehaven.net}}
+%\author{Roger Dingledine and Nick Mathewson and }
+%\institute{The Free Haven Project\\
+%\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}
-  
-  We describe our experiences with deploying Tor, a low-latency
-  anonymous general purpose communication system that has been funded
-  by the U.S.~Navy, DARPA, and the Electronic Frontier Foundation. The
-  basic Tor design supports most applications that run over TCP (those
-  that are SOCKS compliant).
-
-%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.
-
+  There are many unexpected or unexpectedly difficult obstacles to
+  deploying anonymous communications.  Drawing on our experiences deploying
+  Tor (the next-generation onion routing network), we describe social
+  challenges and technical issues that must be faced
+  in building, deploying, and sustaining a scalable, distributed, low-latency
+  anonymity network.
 \end{abstract}
 
 \section{Introduction}
-
-Anonymous communication is full of surprises. In this paper we will
-tell you about some of them. We will describe the challenges arising
-from our experiences with deploying, Tor, a low-latency anonymous general
-purpose communication system. We will discuss some of the difficulties
-we have experienced, how we have met them or, when we have some idea,
-how we plan to meet them. We will also discuss some tough open
-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
-those that we have decided not to explore and why.
-
-Tor is an overlay network, designed
-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 sometimes as much as 80 megabits of average traffic per second.
-
-Tor has a weaker threat model than many anonymity designs in the
-literature, because our foremost goal is to deploy a
-practical and useful network for interactive (low-latency) communications.
-Subject to this restriction, we try to
-provide as much anonymity as we can. In particular, because we
-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.
-
-Users are safe so long as adversaries are unable to
-observe connections as they both enter and leave the Tor network.
-Therefore, Tor's defense lies in having a diverse enough set of servers
-that most real-world
-adversaries 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 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.
+% Your network is not practical unless it is sustainable and distributed.
+Anonymous communication is full of surprises.  This paper discusses some
+unexpected challenges arising from our experiences deploying Tor, a
+low-latency general-purpose anonymous communication system.  We will discuss
+some of the difficulties we have experienced and how we have met them (or how
+we plan to meet them, if we know).  We will also discuss some less
+troublesome open problems that we must nevertheless eventually address.
+%We will describe both those future challenges that we intend to explore and
+%those that we have decided not to explore and why.
+
+Tor is an overlay network for anonymizing TCP streams over the
+Internet~\cite{tor-design}.  It addresses limitations in earlier Onion
+Routing designs~\cite{or-ih96,or-jsac98,or-discex00,or-pet00} by adding
+perfect forward secrecy, congestion control, directory servers, integrity
+checking, configurable exit policies, and location-hidden services using
+rendezvous points.  Tor works on the real-world Internet, requires no special
+privileges or kernel modifications, requires little synchronization or
+coordination between nodes, and provides a reasonable tradeoff between
+anonymity, usability, and efficiency.
+
+We first publicly deployed a Tor network in October 2003; since then it has
+grown to over a hundred volunteer servers and as much as 80 megabits of
+average traffic per second.  Tor's research strategy has focused on deploying
+a network to as many users as possible; thus, we have resisted designs that
+would compromise deployability by imposing high resource demands on server
+operators, and designs that would compromise usability by imposing
+unacceptable restrictions on which applications we support.  Although this
+strategy has
+its drawbacks (including a weakened threat model, as discussed below), it has
+made it possible for Tor to serve many thousands of users, and attract
+research funding from organizations so diverse as ONR and DARPA
+(for use in securing sensitive communications), and the Electronic Frontier
+Foundation (for maintaining civil liberties of ordinary citizens online).
+
+While the Tor design paper~\cite{tor-design} gives an overall view of Tor's
+design and goals, this paper describes some policy, social, and technical
+issues that we face 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 while
+deploying Tor in the wild.  In doing so, we aim to create a research agenda
+for others to help in addressing these issues.  We believe that the issues
+described here will be of general interest to projects attempting to build
+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
-to insist on remaining useful enough to attract many users,
-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 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.
+
+%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
-hop can't trace these connections as they pass through.
+of encryption keys for each hop along the circuit.% to ensure that each
+%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
-that happen within the same short period. Later requests are given a new
+For efficiency, the Tor software uses the same circuit for all the TCP
+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
-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.
+IP packets; it only anonymizes TCP streams and DNS request, and only supports
+connections via SOCKS (see Section~\ref{subsec:tcp-vs-ip}).
 
-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.
+Most servers operators do not want to allow arbitary TCP connections to leave
+their servers.  To address this, Tor provides \emph{exit policies} so that
+each server can block the IP addresses and ports it is unwilling to allow.
+Servers advertise their exit policies to the directory servers, so that
+client can tell which servers will support their connections.
 
 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
-%the other non-goals listed in tor-design.
-
-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 indepth review of related work.
-
-%six-four. crowds. i2p.
+\subsubsection{Threat models and design philosophy}
+The ideal Tor network would be practical, useful and and anonymous. When
+trade-offs arise between these properties, Tor's research strategy has been
+to insist on remaining useful enough to attract many users,
+and practical enough to support them.  Only subject to these
+constraints do we aim to maximize
+anonymity.\footnote{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 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.}
+Because of this strategy, Tor has a weaker threat model than many anonymity
+designs in the literature.   In particular, because we
+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}
-\label{sec:threat-model}
-
-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 timing
-correlation 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
-Section \ref{subsec:mid-latency}).
-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.
+Tor does not attempt to defend against a global observer.  In general, an
+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
+and leaves the network, and so link a user to her chosen communication
+parties.  Known solutions to 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 Section
+\ref{subsec:mid-latency}).  Also, it is not clear that these methods would
+work at all against a minimally active adversary that can introduce timing
+patterns or additional traffic.  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
-matter of system design or technology development. In particular, the
+Many of the issues the Tor project needs to address extend beyond
+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
-  `enclave' configuration.  [XXXX need to resolve this. They would do this
-   for E2E encryption + auth?]
+XXXX clarify.
+\item Maintain the sustainability of the network. XXX sentencize
+%\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}