[or-cvs] Various edits.
syverson at seul.org
syverson at seul.org
Mon Nov 3 21:44:04 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv1873/doc
Modified Files:
tor-design.bib tor-design.tex
Log Message:
Various edits.
Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -d -r1.22 -r1.23
--- tor-design.bib 3 Nov 2003 18:12:14 -0000 1.22
+++ tor-design.bib 3 Nov 2003 21:44:02 -0000 1.23
@@ -49,6 +49,19 @@
pages = {451-463},
}
+
+ at Article{jerichow-jsac98,
+ author = {Anja Jerichow and Jan M\"{u}ller and Andreas
+ Pfitzmann and Birgit Pfitzmann and Michael Waidner},
+ title = {Real-Time Mixes: A Bandwidth-Efficient Anonymity Protocol},
+ journal = {IEEE Journal on Selected Areas in Communications},
+ year = 1998,
+ volume = 16,
+ number = 4,
+ pages = {495--509},
+ month = {May}
+}
+
@inproceedings{tarzan:ccs02,
title = {Tarzan: A Peer-to-Peer Anonymizing Network Layer},
author = {Michael J. Freedman and Robert Morris},
@@ -323,7 +336,35 @@
month = {May},
publisher = {Springer-Verlag, LNCS 1174},
}
- %note = {\url{http://www.onion-router.net/Publications/IH-1996.ps.gz}}
+
+ at InProceedings{federrath-ih96,
+ author = {Hannes Federrath and Anja Jerichow and Andreas Pfitzmann},
+ title = {{MIXes} in Mobile Communication Systems: Location
+ Management with Privacy},
+ title = {Hiding Routing Information},
+ booktitle = {Information Hiding, First International Workshop},
+ pages = {121--135},
+ year = 1996,
+ editor = {R. Anderson},
+ month = {May},
+ publisher = {Springer-Verlag, LNCS 1174},
+}
+
+
+ at InProceedings{reed-protocols97,
+ author = {Michael G. Reed and Paul F. Syverson and David
+ M. Goldschlag},
+ title = {Protocols Using Anonymous Connections: Mobile Applications},
+ booktitle = {Security Protocols: 5th International Workshop},
+ pages = {13--23},
+ year = 1997,
+ editor = {Bruce Christianson and Bruno Crispo and Mark Lomas
+ and Michael Roe},
+ month = {April},
+ publisher = {Springer-Verlag, LNCS 1361}
+}
+
+
@Article{or-jsac98,
author = {Michael G. Reed and Paul F. Syverson and David
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -d -r1.83 -r1.84
--- tor-design.tex 3 Nov 2003 21:05:33 -0000 1.83
+++ tor-design.tex 3 Nov 2003 21:44:02 -0000 1.84
@@ -203,7 +203,7 @@
approach has proven valuable to Tor's portability and deployability.
We have implemented most of the above features. Our source code is
-available under a free license, and we believe it to be unencumbered by
+available under a free license, and, as far as we know, is unencumbered by
patents. We have recently begun deploying a widespread alpha network
to test the design in practice, to get more experience with usability
and users, and to provide a research platform for experimenting with
@@ -338,7 +338,8 @@
protocols (such as HTTP) and relay the application requests themselves
along the circuit.
Making this protocol-layer decision requires a compromise between flexibility
-and anonymity. For example, a system that understands HTTP can strip
+and anonymity. For example, a system that understands HTTP, such as Crowds,
+can strip
identifying information from those requests, can take advantage of caching
to limit the number of requests that leave the network, and can batch
or encode those requests in order to minimize the number of connections.
@@ -441,10 +442,15 @@
see Section~\ref{sec:attacks} for more discussion.
\textbf{No protocol normalization:} Tor does not provide \emph{protocol
-normalization} like Privoxy or the Anonymizer. For complex and variable
+normalization} like Privoxy or the Anonymizer. If anonymization from
+the responder is desired for complex and variable
protocols such as HTTP, Tor must be layered with a filtering proxy such
as Privoxy to hide differences between clients, and expunge protocol
-features that leak identity. Similarly, Tor does not currently integrate
+features that leak identity.
+Note that by this separation Tor can also provide connections that
+are anonymous to the network yet authenticated to the responder, for
+example SSH.
+Similarly, Tor does not currently integrate
tunneling for non-stream-based protocols like UDP; this too must be
provided by an external service.
% Actually, tunneling udp over tcp is probably horrible for some apps.
@@ -1170,7 +1176,7 @@
Rendezvous points are a building block for \emph{location-hidden
services} (also known as \emph{responder anonymity}) in the Tor
network. Location-hidden services allow Bob to offer a TCP
-service, such as a webserver, without revealing its IP.
+service, such as a webserver, without revealing its IP\@.
This type of anonymity protects against distributed DoS attacks:
attackers are forced to attack the onion routing network as a whole
rather than just Bob's IP.
@@ -1255,8 +1261,22 @@
important users get tokens to ensure uninterrupted access to the
service. During normal situations, Bob's service might simply be offered
directly from mirrors, and Bob gives out tokens to high-priority users. If
-the mirrors are knocked down by distributed DoS attacks, those users
-can switch to accessing Bob's service via the Tor rendezvous system.
+the mirrors are knocked down by distributed DoS attacks or even
+physical attack, those users can switch to accessing Bob's service via
+the Tor rendezvous system.
+
+Since Bob's introduction points might themselves be subject to DoS he
+could be faced with a choice between keeping large numbers of
+introduction connections open or risking such an attack. In this case,
+similar to the authentication tokens, he can provide selected users
+with a current list and/or future schedule of introduction points that
+are not advertised in the DHT\@. This is most likely to be practical
+if there is a relatively stable and large group of introduction points
+generally available. Alternatively, Bob could give secret public keys
+to selected users for consulting the DHT\@. All of these approaches
+have the advantage of limiting the damage that can be done even if
+some of the selected high-priority users colludes in the DoS\@.
+
\SubSection{Integration with user applications}
@@ -1278,8 +1298,15 @@
\subsection{Previous rendezvous work}
-Ian Goldberg developed a similar notion of rendezvous points for
-low-latency anonymity systems \cite{ian-thesis}. His design differs from
+Rendezvous points in low-latency anonymity systems were first
+described for use in ISDN telephony \cite{isdn-mixes,jerichow-jsac98}.
+Later low-latency designs used rendezvous points for hiding location
+of mobile phones and low-power location trackers
+\cite{federrath-ih96,reed-protocols97}. Rendezvous for low-latency
+Internet connections was suggested in early Onion Routing work
+\cite{or-ih96}; however, the first published design of rendezvous
+points for low-latency Internet connections was by Ian Goldberg
+\cite{ian-thesis}. His design differs from
ours in three ways. First, Goldberg suggests that Alice should manually
hunt down a current location of the service via Gnutella; whereas our
use of CFS makes lookup faster, more robust, and transparent to the
@@ -1464,8 +1491,7 @@
other nodes. Its ability to directly DoS a neighbor is now limited
by bandwidth throttling. Nonetheless, in order to compromise the
anonymity of the endpoints of a circuit by its observations, a
- hostile node is only significant if it is immediately adjacent to
- that endpoint.
+ hostile node must be immediately adjacent to that endpoint.
\item \emph{Run multiple hostile nodes.} If an adversary is able to
run multiple ORs, and is able to persuade the directory servers
@@ -1605,6 +1631,16 @@
point. But because a service's identity is attached to its public
key, not its introduction point, the service can simply re-advertise
itself at a different introduction point.
+
+\item \emph{Attack multiple introduction points.} If an attacker is
+ able to disable all of the introduction points for a given service,
+ he can block access to the service. However, re-advertisement of
+ introduction points can still be done secretly so that only
+ high-priority clients know the address of the service's introduction
+ points. Such selective secret authorizations can also be issued
+ during normal operation so that the attack cannot also prevent their
+ issuance. In this setting an attack must be able to disable all
+ introduction points for all services to be effective.
\item \emph{Compromise an introduction point.} If an attacker controls
an introduction point for a service, it can flood the service with
@@ -1633,9 +1669,10 @@
Many of these open issues are questions of balance. For example,
how often should users rotate to fresh circuits? Too-frequent
-rotation is inefficient and expensive, but too-infrequent rotation
+rotation is inefficient, expensive and may lead to intersection attacks,
+but too-infrequent rotation
makes the user's traffic linkable. Instead of opening a fresh
-circuit; clients can also limit linkability exit from a middle point
+circuit; clients can also limit linkability by exiting from a middle point
of the circuit, or by truncating and re-extending the circuit, but
more analysis is needed to determine the proper trade-off.
%[XXX mention predecessor attacks?]
@@ -1684,9 +1721,9 @@
%Email from between roger and me to beginning of section above. Fix and move.
Throughout this paper, we have assumed that end-to-end traffic
-analysis will immediately and automatically defeat a low-latency
+confirmation will immediately and automatically defeat a low-latency
anonymity system. Even high-latency anonymity
-systems can be vulnerable to end-to-end traffic analysis, if the
+systems can be vulnerable to end-to-end traffic confirmation, if the
traffic volumes are high enough, and if users' habits are sufficiently
distinct \cite{limits-open,statistical-disclosure}. \emph{Can
anything be done to make low-latency systems resist these attacks as
@@ -1730,7 +1767,7 @@
feasible, what mechanism should be used to prevent adversaries from
signing up many spurious servers?
Second, if clients can no longer have a complete
-picture of the network at all times, how can should they perform
+picture of the network at all times, how can they perform
discovery while preventing attackers from manipulating or exploiting
gaps in client knowledge? Third, if there are too many servers
for every server to constantly communicate with every other, what kind
@@ -1753,7 +1790,10 @@
consider non-clique topologies. A cascade topology may provide more
defense against traffic confirmation.
% XXX Why would it? Cite. -NM
-Does the hydra (many inputs, few outputs) topology work
+%
+% Huh? Do you mean for simple attacks just because of larger anonymity
+% sets? -PS
+Does the hydra topology (many input nodes, few output nodes) work
better? Are we going to get a hydra anyway because most nodes will be
middleman nodes?
@@ -1843,10 +1883,9 @@
% XXX Agree. -NM
\item \emph{Implementing location-hidden servers:} While
Section~\ref{sec:rendezvous} describes a design for rendezvous
- points and location-hidden servers, these feature has not yet been
- implemented. While doing so, will likely encounter additional
- issues, both in terms of usability and anonymity, that must be
- resolved.
+ points and location-hidden servers, these features have not yet been
+ implemented. While doing so we are likely to encounter additional
+ issues that must be resolved, both in terms of usability and anonymity.
\item \emph{Further specification review:} Although we have a public,
byte-level specification for the Tor protocols, this protocol has
not received extensive external review. We hope that as Tor
@@ -1856,7 +1895,7 @@
gain experience in deploying an anonymizing overlay network, and
learn from having actual users. We are now at the point in design
and development where we can start deploying a wider network. Once
- we have are ready for actual users, we will doubtlessly be better
+ we have large numbers of actual users, we will doubtlessly be better
able to evaluate some of our design decisions, including our
robustness/latency trade-offs, our performance trade-offs (including
cell size), our abuse-prevention mechanisms, and
More information about the tor-commits
mailing list