[freehaven-cvs] checkpoint: playing with background and threat model

[arma@seul.org (Roger Dingledine)]

Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/routing-zones

Modified Files:
	routing-zones.bib routing-zones.tex 
Log Message:
checkpoint: playing with background and threat model


Index: routing-zones.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.bib,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- routing-zones.bib	27 Jan 2004 05:26:28 -0000	1.11
+++ routing-zones.bib	27 Jan 2004 18:48:13 -0000	1.12
@@ -4,6 +4,12 @@
   note = {\url{http://www.palfrader.org/echolot/}},
 }
 
+@misc{riot-remap,
+  author = {Riot Admin},
+  title = {The Remailer Geographical Mapping Project},
+  note = {\url{http://riot.eu.org/anon/remap.html}},
+}
+
 @Misc{mixmaster-spec,
    author =      {Ulf M{\"o}ller and Lance Cottrell and Peter
                   Palfrader and Len Sassaman}, 

Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- routing-zones.tex	27 Jan 2004 17:56:36 -0000	1.23
+++ routing-zones.tex	27 Jan 2004 18:48:13 -0000	1.24
@@ -23,7 +23,7 @@
 \institute{MIT Laboratory for Computer Science \email{(feamster@lcs.mit.edu)} \and
 The Free Haven Project \email{(arma@mit.edu)}}
 \maketitle
-%\pagestyle{empty}
+\pagestyle{plain}
 
 \begin{abstract}
 
@@ -67,7 +67,7 @@
 eavesdroppers. Against high-latency \emph{mix networks} such as Mixmaster
 \cite{mixmaster-spec}, an adversary who observes a large volume of
 network traffic can notice over time that certain recipients are more
-likely to receive messages after given senders have transmitted messages
+likely to receive messages after particular senders have transmitted messages
 \cite{disad-free-routes,statistical-disclosure,e2e-traffic}. Low-latency
 networks like Onion Routing~\cite{tor-design} are more directly
 vulnerable: an eavesdropper on both ends of the connection can quickly
@@ -78,22 +78,11 @@
 \begin{tightlist}
 \item {\bf{Batching and pooling:}} The network collects a group of input
 messages and reorders them before they exit, to hinder the adversary
-from learning which message in the batch originated from a given sender
-\cite{chaum81,trickle02}.
-% (Of course, this only works if the system can tolerate some latency.)
+from learning which message in the batch originated from a given
+sender~\cite{chaum81,trickle02}.
 \item {\bf{Padding:}} Senders provide decoy traffic, as well as normal
-traffic, to
-complicate the adversary's attempts to correlate sender and receiver
-\cite{langos02,pipenet,defensive-dropping}.
-%Pipenet~\cite{pipenet} conceals traffic patterns by
-%constant padding on every link, at the cost of robustness. Levine et al
-%show in~\cite{defensive-dropping} that a small amount of dummy padding
-%mixed into the circuit can significant degrade the effectiveness of
-%timing attacks. 
-%Berthold and Langos aim to increase the
-%difficulty of intersection attacks with a scheme for preparing plausible
-%dummy traffic and having other nodes send it for you while you're offline
-%\cite{langos02}; but their design has many practical problems.
+traffic, to complicate the adversary's attempts to correlate sender and
+receiver~\cite{langos02,pipenet,defensive-dropping}.
 \item {\bf{Dispersal:}} Reducing the chance that the adversary sees
 both endpoints for a given communication can entirely block some
 attacks on low-latency networks, and slow down intersection attacks on
@@ -101,16 +90,14 @@
 \end{tightlist}
 
 Dispersal can be achieved by increasing the number of nodes in the
-network, so an adversary of a given strength sees less of the network
-\cite{econymics,bennett:pet2003,morphmix:fc04}; by arranging the overlay
+network, so an adversary of a given strength sees less of the
+network~\cite{econymics,bennett:pet2003,morphmix:fc04}; by arranging
+the overlay
 topology so messages can enter or exit at more places in the network
 (compared to a cascade topology~\cite{disad-free-routes});
 or by \emph{jurisdictional arbitrage} --- coordinating network behavior
 so each transaction includes zones (i.e., jurisdictions) controlled by
 several different adversaries.
-% would be nice to cite something for jurisdictional arbitrage, but i
-% seem to be the only person who's said that phrase in a paper, and
-% i think it would look bad.
 
 In this paper, we investigate a variant of jurisdictional arbitrage by
 taking advantage of the fact that the Internet is divided into thousands
@@ -119,27 +106,31 @@
 we can assess the vulnerability of existing mix networks to certain classes
 of adversary.  Specifically, we define a {\em jurisdictional
 independence} metric that reflects the probability that the path to the
+% XXX unless it reflects something else. intra-network independence and
+% user-network independence? hm.
 entry point of a mix network and the path from the exit point will
 traverse the same AS.  We then consider the node selection algorithms of
-existing mix networks, such as Tor~\cite{tor-design} and
-Mixmaster~\cite{mixmaster-spec} and evaluate the independence metric for
-each of these networks.
+two existing mix networks---Tor~\cite{tor-design} and
+Mixmaster~\cite{mixmaster-spec}---and evaluate the independence metric for
+these networks.
 
 We find that both Tor and Mixmaster have multiple mix nodes in the same
 autonomous system.  Users of these networks should take care to avoid
-selecting two nodes from the same AS, if at all possible.  Furthermore,
+selecting two nodes from the same AS.  Furthermore,
 we note that {\bf XXX some property about mix paths and AS paths}.
 Users of these networks should take extreme care to select mix nodes to
 minimize the likelihood that the entry path and exit path for the mix
 network do not traverse the same AS.  We also argue that, because
-paths between mix nodes often cross the same AS, that a user's
+paths between mix nodes often cross the same AS, a user's
 vulnerability to eavesdropping does not decrease proportionally with the
 number of mix nodes in the path.
 
 \section{Background}
 
-In this section, we provide necessary background information on
-anonymizing networks and on Internet routing.  We describe the different
+Here
+%we provide necessary background information on
+%anonymizing networks and on Internet routing.
+we describe the different
 types of mix networks and present a brief explanation of the types of
 attacks that each type of mix network must protect against.  Because we
 argue that designers of mix networks should, in certain cases, pay
@@ -156,31 +147,42 @@
 toward their destinations.
 
 Subsequent anonymity systems have diverged in two directions. Systems
-like Babel~\cite{babel}, Mixmaster~\cite{mixmaster-spec}, and Mixminion~
-\cite{minion-design} aim to defend against powerful adversaries, but at
+like Babel~\cite{babel}, Mixmaster~\cite{mixmaster-spec}, and
+Mixminion~\cite{minion-design} aim to defend against powerful adversaries,
+but at
 the cost of requiring high and variable latency. Other systems, such as
 Onion Routing or its successor Tor~\cite{tor-design,or-jsac98}, support
 low-latency transactions such as web browsing, but necessarily have a
 weaker threat model.
 
 Anonymity networks aim to protect against a wide variety of both passive
-and active attacks~\cite{back01,raymond00}, but in this paper we do
-not consider the details of the anonymity network itself. Instead,
-we treat the network as a black box and consider only the endpoints
-(entry node and exit node) for each given transaction. Endpoint
-attacks include simple timing and counting attacks against
-low-latency systems~\cite{defensive-dropping,SS03}, and long-term
-intersection or disclosure attacks against high-latency systems
-\cite{disad-free-routes,statistical-disclosure,e2e-traffic}.
+and active attacks~\cite{back01,raymond00}. Such attacks generally
+fall into two categories: attacks inside the network, and endpoint
+attacks. Attacks inside the network aim to partition anonymity sets
+through passive observation~\cite{disad-free-routes,minion-design}
+or active traffic manipulation~\cite{trickle02}, or otherwise reduce
+the set of suspects for a given transaction. Endpoint attacks treat the
+network as a black box and consider only the entry node and exit node
+for the transaction; such attacks include simple timing and counting
+attacks against low-latency systems~\cite{defensive-dropping,SS03},
+and long-term intersection or disclosure attacks against high-latency
+systems \cite{disad-free-routes,statistical-disclosure,e2e-traffic}.
 
-Mixmaster, Mixminion, and Tor are deployed networks with
-dozens of nodes each. We will describe their threat models in
+Mixmaster and Tor are deployed networks with dozens of nodes
+around the world (tables showing the current networks can be
+found in the Appendix). We will describe their threat models in
 Section~\ref{sec:threat-model} and their path selection algorithms in
 Section~\ref{sec:path-selection}.
 
-{\bf XXX talk about http://riot.eu.org/anon/remap.html here, since it's
-  basically the only piece of related work.  note that it doesn't look
-  at paths.  Their website actually doesn't say much.}
+The idea of jurisdictional independence is not new. Tim May and
+Eric Hughes wrote about it in early posts to the cypherpunks list.
+Mixmaster operators attempt to track which ISPs can control
+each node, to get an informal intuition of the independence of the
+network~\cite{riot-remap}. Even designs published in the literature, such
+as Tarzan and Morphmix, aim to provide collusion resistance by comparing
+the IP of each peer~\cite{freedman:ccs02,morphmix:fc04}. Our contribution
+is to consider actual anonymity networks in the context of actual Internet
+routing tables, and come up with ways to quantify the results.
 
 \subsection{Overview of Internet Routing and Topology}
 
@@ -333,27 +335,28 @@
 be less willing to face the increased accountability and risk associated
 with obtaining multiple unapproved subpoenas.
 
-By requiring the adversary to control multiple ASes, we raise the bar
-for breaking the anonymity of the system. But we must consider the two
-types of anonymity network separately.
-
-\subsection{High-latency anonymity networks}
+By requiring the adversary to control multiple ASes, we raise the
+bar for breaking the anonymity of the system. To understand more,
+we must consider which attacks are easiest and most effective
+against different classes of anonymity network. We divide
+attacks into network attacks and endpoint attacks, as described in
+Section~\ref{subsec:background-anonymity}. Intra-network attacks exploit
+design issues in the protocol to reduce Alice's anonymity set. For
+example, an adversary who learns the first half of Alice's path in a
+\emph{high-latency} network like Mixmaster learns where to make his next
+phone call to track Alice's recipient.
 
-Deployed remailer networks use latency and batching to
+Such intra-network attacks are also applicable to \emph{low-latency}
+networks like Tor. Paths are short in these networks to
+maintain usability---typically they are 3 hops, to 
 
 
 
-\subsection{Low-latency anonymity networks}
 
 
 
-Our goal is to assess the risk from an adversary who controls one
-Internet routing zone, and consider protocol changes that will require
-the adversary to own at least two such zones to do any damage. Thus we
-consider only endpoint attacks---as we show above they can be sufficient
-to break anonymity, and without observing both endpoints the adversary
-cannot possibly learn about both the initiator (Alice) and the responder
-(Bob).
+endpoint attacks can be sufficient
+to break anonymity,
 
 Note that a successful endpoint attack against a high-latency system like
 Mixmaster takes a lot more time and effort than a successful endpoint
@@ -389,8 +392,9 @@
 of currently available nodes. In Mixmaster, clients examine the output
 of ``pinger'' software that measures node reliability and publishes keys
 and addresses for each remailer~\cite{echolot}. In Tor, clients download
-a similar network snapshot from special nodes called directory servers
-that play a role similar to pingers~\cite{tor-design}.  The pingers and
+a similar network snapshot from special nodes called directory
+servers~\cite{tor-design} that play a role similar to pingers.
+The pingers and
 directory servers note whether each node is an \emph{exit node}---meaning
 that node's operator is willing to allow traffic to exit the network
 from this node (some operators choose instead to be middleman nodes,

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/