# [or-cvs] give us page numbers, cut some more

Update of /home2/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/home2/arma/work/onion/cvs/tor/doc/design-paper

Modified Files:
challenges.tex
Log Message:
give us page numbers, cut some more

Index: challenges.tex
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -d -r1.48 -r1.49
--- challenges.tex	8 Feb 2005 01:40:19 -0000	1.48
+++ challenges.tex	8 Feb 2005 01:57:19 -0000	1.49
@@ -30,7 +30,7 @@

\maketitle
-\pagestyle{empty}
+%\pagestyle{empty}

\begin{abstract}
There are many unexpected or unexpectedly difficult obstacles to
@@ -891,16 +891,14 @@
arrival times: as timing variance increases, timing correlation attacks
require increasingly more data~\cite{e2e-traffic}. Can we improve Tor's
resistance to these attacks without losing too much usability?
-%by introducing batching
-%and delaying strategies to the Tor messages?

First, we need to learn whether we can trade a small increase in latency
for a large anonymity increase, or if we'll end up trading a lot of
latency for a small security gain. It would be worthwhile even if we
can only protect certain use cases, such as infrequent short-duration
-transactions.  In order to answer this question, we might
-try to adapt the techniques of~\cite{e2e-traffic} to a lower-latency mix
-network, where instead of sending messages, users send batches
+transactions.  To answer this question, we might
+adapt the techniques of~\cite{e2e-traffic} to a lower-latency mix
+network, where the messages are batches
of cells in temporally clustered connections.

Once the anonymity questions are answered, we need to consider usability.  If
@@ -944,7 +942,6 @@
we have always approached padding lest the overhead cost us too much
performance or too many volunteers.

-
\subsection{Measuring performance and capacity}
\label{subsec:performance}

@@ -1114,7 +1111,6 @@
of helper nodes. This insecurity means that they may not be suitable as
publishing systems that aim to provide long-term security.
-%Also, they're brittle in terms of intersection and observation attacks.

\emph{Hot-swap} hidden services, where more than one location can
provide the service and loss of any one location does not imply a
@@ -1145,8 +1141,6 @@
\subsection{Trust and discovery}
\label{subsec:trust-and-discovery}

-[arma will edit this and expand/retract it]
-
The published Tor design adopted a deliberately simplistic design for
authorizing new nodes and informing clients about Tor nodes and their status.
In the early Tor designs, all nodes periodically uploaded a signed description
@@ -1548,60 +1542,12 @@
\end{figure}

-\section{Things to cut?}
-\subsection{Peer-to-peer / practical issues}
-
-[leave this section for now, and make sure things here are covered
-elsewhere. then remove it.]
-
-Making use of nodes with little bandwidth. How to handle hammering by
-certain applications.
-
-Handling nodes that are far away from the rest of the network, e.g. on
-the continents that aren't North America and Europe. High latency,
-often high packet loss.
+Making use of nodes with little bandwidth, or high latency/packet loss.

Running Tor nodes behind NATs, behind great-firewalls-of-China, etc.
Restricted routes. How to propagate to everybody the topology? BGP
style doesn't work because we don't want just *one* path. Point to
Geoff's stuff.

-\subsection{Caching stuff: If a topic's gotta go for space, I think this
-is the best candidate}
-
-The attacks in \cite{attack-tor-oak05} are also dependent on
-cooperation of the responding application or the ability to modify or
-monitor the responder stream, in order of decreasing attack
-effectiveness.  So, another way to slow some of these attacks
-would be to cache responses at exit nodes where possible, as it is with
-DNS lookups and cacheable HTTP responses.  Caching would, however,
-create threats of its own. First, a Tor network is expected to contain
-hostile nodes. If one of these is the repository of a cache, the
-attack is still possible. Though more work to set up a Tor node and
-cache repository, the payoff of such an attack is potentially
-higher.
-%To be
-%useful, such caches would need to be distributed to any likely exit
-%nodes of recurred requests for the same data.
-%   Even local caches could be useful, I think. -NM
-%
-Besides allowing any other insider attacks, caching nodes would hold a
-record of destinations and data visited by Tor users reducing forward
-anonymity. Worse, for the cache to be widely useful much beyond the
-client that caused it there would have to either be a new mechanism to
-distribute cache information around the network and a way for clients
-to make use of it or the caches themselves would need to be
-distributed widely. Either way the record of visited sites and