[or-cvs] Add design goals section

Nick Mathewson nickm at seul.org
Tue Oct 21 17:43:28 UTC 2003

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv11720/doc

Modified Files:
Log Message:
Add design goals section

Index: tor-design.tex
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- tor-design.tex	21 Oct 2003 08:09:55 -0000	1.12
+++ tor-design.tex	21 Oct 2003 17:43:26 -0000	1.13
@@ -409,8 +409,6 @@
 if, as assumed above, our goal is to hide which local-COR is talking to
 which local-COR.
 \SubSection{Known attacks against low-latency anonymity systems}
@@ -438,7 +436,77 @@
 \Section{Design goals and assumptions}
-[XXX Perhaps the threat model belongs here.]
+% Are these really our goals? ;) -NM
+Like other low-latency anonymity designs, Tor seeks to frustrate
+attackers from linking communication partners, or from linking
+multiple communications to or from a single point.  Within this
+overriding goal, however, several design considerations have directed
+Tor's evolution.
+First, we have tried to build a {\bf deployable} system.  [XXX why?]
+This requirement precludes designs that are expensive to run (for
+example, by requiring more bandwidth than volunteers are easy to
+provide); designs that place a heavy liability burden on operators
+(for example, by allowing attackers to implicate operators in illegal
+activities); and designs that are difficult or expensive to implement
+(for example, by requiring kernel patches to many operating systems,
+or ).
+Second, the system must be {\bf usable}.  A hard-to-use system has
+fewer users---and because anonymity systems hide users among users, a
+system with fewer users provides less anonymity.  Thus, usability is
+not only a convenience, but is a security requirement for anonymity
+Third, the protocol must be {\bf extensible}, so that it can serve as
+a test-bed for future research in low-latency anonymity systems.
+(Note that while an extensible protocol benefits researchers, there is
+a danger that differing choices of extensions will render users
+distinguishable.  Thus, implementations should not permit different
+protocol extensions to coexist in a single deployed network.)
+The protocol's design and security parameters must be {\bf
+conservative}.  Additional features impose implementation and
+complexity costs. [XXX Say that we don't want to try to come up with
+speculative solutions to problems we don't KNOW how to solve? -NM]
+[XXX mention something about robustness?  But we really aren't that
+  robust.  We just assume that tunneled protocols tolerate connection
+  loss. -NM]
+In favoring conservative, deployable designs, we have explicitly
+deferred a number of goals---not because they are not desirable in
+anonymity systems---but because solving them is either solved
+elsewhere, or an area of active research without a generally accepted
+Unlike Tarzan or Morphmix, Tor does not attempt to scale to completely
+decentralized peer-to-peer environments with thousands of short-lived
+Tor does not claim to provide a definitive solution to end-to-end
+timing or intersection attacks for users who do not run their own
+Onion Routers.
+Tor does not provide ``protocol normalization'' like the Anonymizer,
+Privoxy, or XXX.  In order to provide client indistinguishibility for
+complex and variable protocols such as HTTP, Tor must be layered with
+a proxy such as Privoxy or XXX.  Similarly, Tor does not currently
+integrate tunneling for non-stream-based protocols; this too must be
+provided by an external service.
+Tor is not steganographic. It doesn't try to conceal which users are
+sending or receiving communications via Tor.
+- Threat model
+- Mostly reliable nodes: not trusted.
+- Small group of trusted dirserv ops
+- Many users of diff bandwidth come and go.
+[XXX what else?]

More information about the tor-commits mailing list