[or-cvs] clean-up based on the oakland reviews

[Roger Dingledine]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.bib tor-design.tex 
Log Message:
clean-up based on the oakland reviews


Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- tor-design.bib	17 Jan 2004 16:20:07 -0000	1.28
+++ tor-design.bib	17 Jan 2004 17:43:38 -0000	1.29
@@ -1074,6 +1074,17 @@
   note={\url{http://www.datenschutzzentrum.de/material/themen/presse/anon-bka_e.htm}}
 }
 
+ at article{shsm03,
+  title = {Using Caching for Browsing Anonymity}, 
+  author = {Anna Shubina and Sean Smith}, 
+  journal = {ACM SIGEcom Exchanges}, 
+  volume = {4}, 
+  number = {2}, 
+  year = {2003}, 
+  month = {September}, 
+  www_pdf_url = {http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf}, 
+  www_section = {Anonymous communication}, 
+}
 
 %%% Local Variables: 
 %%% mode: latex

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.133
retrieving revision 1.134
diff -u -d -r1.133 -r1.134
--- tor-design.tex	17 Jan 2004 16:20:07 -0000	1.133
+++ tor-design.tex	17 Jan 2004 17:43:38 -0000	1.134
@@ -514,7 +514,7 @@
 The Tor network is an overlay network; each onion router (OR)
 runs as a normal
 user-level process without any special privileges.
-Each onion router maintains a long-term TLS \cite{TLS}
+Each onion router maintains a TLS \cite{TLS}
 connection to every other onion router.
 %(We discuss alternatives to this clique-topology assumption in
 %Section~\ref{sec:maintaining-anonymity}.)
@@ -530,16 +530,16 @@
 of the circuit connects to the destinations of
 the TCP streams and relays data.
 
-Each onion router uses three public keys: a long-term identity key, a
-short-term onion key, and a short-term link key.  The identity
+Each onion router maintains a long-term identity key and a short-term
+onion key. The identity
 key is used to sign TLS certificates, to sign the OR's \emph{router
 descriptor} (a summary of its keys, address, bandwidth, exit policy,
 and so on), and (by directory servers) to sign directories. Changing
 the identity key of a router is considered equivalent to creating a
 new router. The onion key is used to decrypt requests
-from users to set up a circuit and negotiate ephemeral keys. Finally,
-link keys are used by the TLS protocol when communicating between
-onion routers. Each short-term key is rotated periodically and
+from users to set up a circuit and negotiate ephemeral keys. Additionally,
+the TLS protocol also establishes a short-term link key when communicating
+between onion routers. Each short-term key is rotated periodically and
 independently, to limit the impact of key compromise.
 
 Section~\ref{subsec:cells} presents the fixed-size
@@ -578,7 +578,7 @@
 and \emph{destroy} (to tear down a circuit).
 
 Relay cells have an additional header (the relay header) after the
-cell header, containing a stream identifier (many streams can
+cell header, containing a streamID (stream identifier: many streams can
 be multiplexed over a circuit); an end-to-end checksum for integrity
 checking; the length of the relay payload; and a relay command.
 The entire contents of the relay header and the relay cell payload
@@ -769,15 +769,17 @@
 the chosen OR.
 
 There's a catch to using SOCKS, however---some applications pass the
-alphanumeric hostname to the proxy, while others resolve it into an IP
-address first and then pass the IP address to the proxy.  If the
-application does DNS resolution first, Alice will thereby
-reveal her destination to the DNS server.  Common applications
+alphanumeric hostname to the Tor client, while others resolve it into
+an IP address first and then pass the IP address to the Tor client. If
+the application does DNS resolution first, Alice will thereby reveal her
+destination to the remote DNS server, rather than sending the hostname
+through the Tor network to be resolved at the far end. Common applications
 like Mozilla and SSH have this flaw.
 
 In the case of Mozilla, the flaw is easy to address: the filtering HTTP
-proxy called Privoxy does the SOCKS call safely, and Mozilla talks to
-Privoxy safely. But a portable general solution, such as is needed for
+proxy called Privoxy gives a hostname to the Tor client, so Alice's
+computer never does DNS resolution.
+But a portable general solution, such as is needed for
 SSH, is
 an open problem. Modifying or replacing the local nameserver
 can be invasive, brittle, and not portable. Forcing the resolver
@@ -807,18 +809,16 @@
 vulnerable to a malleability attack: though the attacker could not
 decrypt cells, any changes to encrypted data
 would create corresponding changes to the data leaving the network.
-(Even an external adversary could do this, despite link encryption, by
-inverting bits on the wire.)
-
 This weakness allowed an adversary to change a padding cell to a destroy
 cell; change the destination address in a \emph{relay begin} cell to the
 adversary's webserver; or change an FTP command from
-{\tt dir} to {\tt rm~*}. Any OR or external adversary
-along the circuit could introduce such corruption in a stream, if it
-knew or could guess the encrypted content.
+{\tt dir} to {\tt rm~*}. Any adversary who could guess the encrypted
+content could introduce such corruption in a stream. (Even an external
+adversary could do this, because the link encryption similarly used a
+stream cipher.)
 
-Tor prevents external adversaries from mounting this attack by
-using TLS on its links, which provides integrity checking.
+Tor uses TLS on its links---its integrity checking
+prevents external adversaries from mounting this attack.
 Addressing the insider malleability attack, however, is
 more complex.
 
@@ -828,7 +828,7 @@
 impose a message-expansion overhead at each hop, and so we would have to
 either leak the path length or waste bytes by padding to a maximum
 path length. Second, these solutions can only verify traffic coming
-from Alice: ORs would not be able to include suitable hashes for
+from Alice: ORs would not be able to produce suitable hashes for
 the intermediate hops, since the ORs on a circuit do not know the
 other ORs' session keys. Third, we have already accepted that our design
 is vulnerable to end-to-end timing attacks; tagging attacks performed
@@ -978,12 +978,14 @@
 (comparatively expensive) half of the handshake at no real computational
 cost to the attacker.
 
-Several approaches exist to address these attacks. First, ORs may
+We have not yet implemented any defenses for these attacks, but several
+approaches are possible. First, ORs can
 require clients to solve a puzzle \cite{puzzles-tls} while beginning new
 TLS handshakes or accepting \emph{create} cells.  So long as these
 tokens are easy to verify and computationally expensive to produce, this
-approach limits the attack multiplier.  Additionally, ORs may limit
-the rate at which they accept create cells and TLS connections, so that
+approach limits the attack multiplier.  Additionally, ORs can limit
+the rate at which they accept \emph{create} cells and TLS connections,
+so that
 the computational work of processing them does not drown out the
 symmetric cryptography operations that keep cells
 flowing.  This rate limiting could, however, allow an attacker
@@ -993,8 +995,8 @@
 
 Adversaries can also attack the Tor network's hosts and network
 links. Disrupting a single circuit or link breaks all streams passing
-along that part of the circuit. Indeed, this same loss of service
-occurs when a router crashes or its operator restarts it. The current
+along that part of the circuit. Users similarly lose service
+when a router crashes or its operator restarts it. The current
 Tor design treats such attacks as intermittent network failures, and
 depends on users and applications to respond or recover as appropriate. A
 future design could use an end-to-end TCP-like acknowledgment protocol,
@@ -1040,9 +1042,11 @@
 exit (if one exists) is a more secure way for a client to connect to a
 given host or network---an external adversary cannot eavesdrop traffic
 between the private exit and the final destination, and so is less sure of
-Alice's destination and activities. Most onion routers will function as
+Alice's destination and activities. Most onion routers in the current
+network function as
 \emph{restricted exits} that permit connections to the world at large,
-but prevent access to certain abuse-prone addresses and services.
+but prevent access to certain abuse-prone addresses and services such
+as SMTP.
 Additionally, in some cases the OR can authenticate clients to
 prevent exit abuse without harming anonymity \cite{or-discex00}.
 
@@ -1052,12 +1056,13 @@
 %nearly all participants will be honest, and end-to-end authentication
 %can be assumed for important traffic.
 
-Many administrators will use port restrictions to support only a
+Many administrators use port restrictions to support only a
 limited set of services, such as HTTP, SSH, or AIM.
 This is not a complete solution, of course, since abuse opportunities for these
 protocols are still well known.
 
-A further solution may be to use proxies to clean traffic for certain
+We have not yet encountered any abuse in the deployed network, but if
+we do we should consider using proxies to clean traffic for certain
 protocols as it leaves the network.  For example, much abusive HTTP
 behavior (such as exploiting buffer overflows or well-known script
 vulnerabilities) can be detected in a straightforward manner.
@@ -1112,12 +1117,11 @@
 adversary to efficiently deploy resources
 against a target \cite{minion-design}.
 
-
 Tor uses a small group of redundant, well-known onion routers to
 track changes in network topology and node state, including keys and
 exit policies.  Each such \emph{directory server} acts as an HTTP
-server, so participants can fetch current network state and router
-lists, and so other ORs can upload
+server, so clients (circuit initiators) can fetch current network state
+and router lists, and so other ORs can upload
 state information.  Onion routers periodically publish signed
 statements of their state to each directory server. The directory servers
 combine this state information with their own views of network liveness,
@@ -1125,6 +1129,8 @@
 network state. Client software is
 pre-loaded with a list of the directory servers and their keys,
 to bootstrap each client's view of the network.
+% XXX this means that clients will be forced to upgrade as the
+% XXX dirservers change or get compromised. argue that this is ok.
 
 When a directory server receives a signed statement for an OR, it
 checks whether the OR's identity key is recognized. Directory
@@ -1183,7 +1189,8 @@
 To avoid attacks where a router connects to all the directory servers
 but refuses to relay traffic from other routers, the directory servers
 must build circuits and use them to anonymously test router reliability
-\cite{mix-acc}.
+\cite{mix-acc}. Unfortunately, this defense is not yet designed or
+implemented.
 
 Using directory servers is simpler and more flexible than flooding.
 Flooding is expensive, and complicates the analysis when we
@@ -1201,10 +1208,10 @@
 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 address.
+service, such as a webserver, without revealing his IP address.
 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 address.
+attackers are forced to attack the onion routing network
+because they do not know Bob's IP address.
 
 Our design for location-hidden servers has the following goals.
 \textbf{Access-controlled:} Bob needs a way to filter incoming requests,
@@ -1817,7 +1824,9 @@
 \emph{Incentives:} Volunteers who run nodes are rewarded with publicity
 and possibly better anonymity \cite{econymics}. More nodes means increased
 scalability, and more users can mean more anonymity. We need to continue
-examining the incentive structures for participating in Tor.
+examining the incentive structures for participating in Tor. Further,
+we need to explore more approaches to limiting abuse, and understand
+why most people don't bother using privacy systems.
 
 \emph{Cover traffic:} Currently Tor omits cover traffic---its costs
 in performance and bandwidth are clear but its security benefits are
@@ -1831,7 +1840,8 @@
 % This should go in the spec and todo, but not the paper yet. -RD
 
 \emph{Caching at exit nodes:} Perhaps each exit node should run a
-caching web proxy, to improve anonymity for cached pages (Alice's request never
+caching web proxy \cite{shsm03}, to improve anonymity for cached pages
+(Alice's request never
 leaves the Tor network), to improve speed, and to reduce bandwidth cost.
 On the other hand, forward security is weakened because caches
 constitute a record of retrieved files.  We must find the right
@@ -1851,8 +1861,8 @@
 so we are likely to encounter additional issues that must be resolved,
 both in terms of usability and anonymity.
 
-\emph{Further specification review:} Although have a public
-byte-level specification for the Tor protocols \cite{tor-spec}, it needs
+\emph{Further specification review:} Our public
+byte-level specification \cite{tor-spec} needs
 extensive external review.  We hope that as Tor
 is more widely deployed, more people will examine its
 specification.