[tor-commits] [tor-design-2012/master] Revise "other design decisions" section

[nickm at torproject.org]

commit 69b010d08f259daaebd3f7360db9882612f19b4f
Author: Nick Mathewson <nickm at torproject.org>
Date:   Tue Nov 13 23:02:11 2012 -0500

    Revise "other design decisions" section
---
 todo                |    5 +++--
 tor-design-2012.tex |   48 +++++++++++++++++++-----------------------------
 2 files changed, 22 insertions(+), 31 deletions(-)

diff --git a/todo b/todo
index ac44c7f..af508bf 100644
--- a/todo
+++ b/todo
@@ -6,6 +6,7 @@ LEGEND:
    o Done
    . Partially done
    ? Do we really need to do this?
+   X Abandoned: we don't need to do this.
 
 ITEMS:
 
@@ -24,7 +25,7 @@ ITEMS:
      o stream isolation
    . Integrate content from the third blog post [steven]
      o link protocol tls
-     ? rise and fall of .exit
+     X rise and fall of .exit
      . controller protocol
      o torbutton
      o tor browser bundle
@@ -37,7 +38,7 @@ ITEMS:
    o Revise tor-design up to "opening and closing streams" [nick]
    . Revise tor-design "opening and closing streams" onward [steven]
    o Revise hidden services section [nick]
-   . Revise "other design decisions" [nick]
+   o Revise "other design decisions" [nick]
 
 CAN DO AFTER SPONSOR DEADLINE:
    - Revise related work [steven]
diff --git a/tor-design-2012.tex b/tor-design-2012.tex
index 2f48cbb..035bf0d 100644
--- a/tor-design-2012.tex
+++ b/tor-design-2012.tex
@@ -1452,7 +1452,8 @@ others.
 
 First of all, there are several CPU-consuming denial-of-service
 attacks wherein an attacker can force an OR to perform expensive
-cryptographic operations.  For example, an attacker can fake the
+cryptographic operations at little cost to the attacker.
+For example, an attacker can fake the
 start of a TLS handshake, forcing the OR to carry out its
 (comparatively expensive) half of the handshake at no real
 computational cost to the attacker.
@@ -1470,8 +1471,6 @@ symmetric cryptography operations that keep cells flowing.  This
 rate limiting could, however, allow an attacker to slow down
 other users when they build new circuits.
 
-% What about link-to-link rate limiting?
-
 The Tor network itself can be exploited as a DoS amplifier,
 because for every relay cell sent into an OP, a cell is
 generated at each hop on the circuit. An adversary could create
@@ -1494,9 +1493,6 @@ requests and so cannot generate a path of longer than 8 hops.
 This does not however prevent an adversary tunneling Tor over
 Tor, and connecting from an exit node back to the Tor network.
 
-% Mention long-path defense -NM
-% Believed done -SJM
-
 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. Users similarly lose
@@ -1510,19 +1506,22 @@ require more buffering at the network edges, however, and the
 performance and anonymity implications from this extra
 complexity still require investigation.
 
-% Mention asymmetries in protocols, where a little effort from an attacker
-% can make Tor do more calculation.  That's bad. -NM
-
-\subsection{Exit policies and abuse}
+In general, deliberate denial of service attacks have not yet had a
+noticeable impact on the Tor network in the wild.  While we are
+aware to the possibility, and looking for more ways to mitigate
+possible DoS attack vectors, we are currently more concerned with
+circumstances under which misbehaving nodes accidentally ``attack''
+part of the network.  For example, our decision to have the
+directory authorities act both as the initial contact point for
+clients to get directory information has led to clients placing
+excessive load on those authorities during times when they couldn't
+find pieces of directory information.
+
+\subsection{Exit policies, node history, and abuse}
 \label{subsec:exitpolicies}
-% This whole section's introduction should get rewritten based on our
-% experiences with the network. -NM
-
-% The thing with exit policies isn't so much (as we phrase it) a "mitigate
-% abuse" thing.  It's about allowing servers who can't tolerate *any* abuse
-% to contribute to the network.  Our thinking was kinda muddled there. -NM
 
-Exit abuse is a serious barrier to wide-scale Tor
+The prospect of exit abuse limits the number of users willing to run
+Tor nodes. Exit abuse is a serious barrier to wide-scale Tor
 deployment. Anonymity presents would-be vandals and abusers with
 an opportunity to hide the origins of their
 activities. Attackers can harm the Tor network by implicating
@@ -1531,17 +1530,8 @@ use IP-based authentication (such as institutional mail or
 webservers) can be fooled by the fact that anonymous connections
 appear to originate at the exit OR.
 
-We stress that Tor does not enable any new class of
-abuse. Spammers and other attackers already have access to
-thousands of misconfigured systems worldwide, and the Tor
-network is far from the easiest way to launch attacks.  But
-because the onion routers can be mistaken for the originators of
-the abuse, and the volunteers who run them may not want to deal
-with the hassle of explaining anonymity networks to irate
-administrators, we must block or limit abuse through the Tor
-network.
-
-To mitigate abuse issues, each onion router's \emph{exit policy}
+To enable volunteers to run nodes without having to necessarily
+worry about these abuse issues, each onion router's \emph{exit policy}
 describes to which external addresses and ports the router will
 connect. On one end of the spectrum are \emph{open exit} nodes
 that will connect anywhere. On the other end are
@@ -1551,7 +1541,7 @@ local host or network.  A private exit can allow a client to
 connect to a given host or network more securely---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 in the current
+destination and activities. Many 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 such as SMTP.  The OR might