[tor-commits] [tor-design-2012/master] Quick pass to revise the rest of the tor-design section

[nickm at torproject.org]

commit f77b7a6e255319c259daf0d060444d2909fd8d3e
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Nov 14 01:13:57 2012 -0500

    Quick pass to revise the rest of the tor-design section
---
 tor-design-2012.tex |   57 +++++++++++++++++++++++++--------------------------
 1 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/tor-design-2012.tex b/tor-design-2012.tex
index 38a6eed..43cf08b 100644
--- a/tor-design-2012.tex
+++ b/tor-design-2012.tex
@@ -1140,8 +1140,11 @@ reply to notify the application of its success. The OP now
 accepts data from the application's TCP stream, packaging it
 into \emph{relay data} cells and sending those cells along the
 circuit to the chosen OR.
-% Mention the optimistic data extension: clients can send data before getting
-% a relay_connected cell. -NM
+
+(As an optimization, to avoid a round-trip while waiting for a
+connected reply, clients may send data immediately after the
+connected cell.  The need to be ready to send the same data to
+another stream, though, if no connected cell arrives.)
 
 There's a catch to using SOCKS, however---some applications pass
 the alphanumeric hostname to the Tor client, while others
@@ -1153,8 +1156,6 @@ resolved at the far end. Common applications like Firefox and
 SSH need to be configured to use SOCKS4A or SOCKS5 (with the
 option to send hostnames rather than IP address) to avoid this
 vulnerability.
-% No longer true wrt mozilla and SSH. -NM
-% Believed done -SJM
 
 With Firefox, the Torbutton add-on ensures that the browser
 sends requests via Tor by configuring Firefox to correctly use a
@@ -1177,12 +1178,10 @@ Other applications, which can be configured to use SOCKS (and
 send the proxy a hostname rather than IP address), may be
 connected directly to Tor. Other options available are to
 intercept calls to the resolver and sockets libraries with
-\emph{torsocks} or to use a firewall (Tor supports BSD and
-Linux's in-built firewall) to intercept outgoing DNS requests
+\emph{torsocks} or to use an operating system firewall's transparent
+port-forwarding mechanism (Tor supports BSD and
+Linux's in-built port-forwarding) to intercept outgoing DNS requests
 and TCP connections, sending them via Tor.
-% We don't recommend privoxy any more.  Proxies are one solution though.  But
-% for web, we think you need a custom browser. -NM
-% Believed done -SJM
 
 Closing a Tor stream is analogous to closing a TCP stream: it
 uses a two-step handshake for normal operation, or a one-step
@@ -1216,8 +1215,8 @@ modify data. Addressing the insider malleability attack,
 however, is more complex.
 
 We could do integrity checking of the relay cells at each hop,
-either by including hashes or by using an authenticating cipher
-mode like EAX~\cite{eax}, but there are some problems. First,
+either by including MACs or by using an authenticating cipher
+mode like GCM~\cite{gcm}, but there are some problems. First,
 these approaches 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
@@ -1228,10 +1227,6 @@ session keys. Third, we have already accepted that our design is
 vulnerable to end-to-end timing attacks; so tagging attacks
 performed within the circuit provide no additional information
 to the attacker.
-% This "no additional information to the attacker" claim is less great than
-% it might have seemed in 2004. We're looking towards wide-block approaches
-% here instead.  Also we should really not cite EAX and hashes but probably
-% GCM and MACs as the likelier alternatives. -NM
 
 Thus, we check integrity only at the edges of each
 stream. (Remember that in our leaky-pipe circuit topology, a
@@ -1244,8 +1239,6 @@ cells they create, and include with each relay cell the first
 four bytes of the current digest.  Each also keeps a SHA-1
 digest of data received, to verify that the received hashes are
 correct.
-% Mention that sha-1 is showing its age, and we're moving away from it in our
-% next relay protocol. -NM
 
 To be sure of removing or modifying a cell, the attacker must be
 able to deduce the current digest state (which depends on all
@@ -1260,6 +1253,17 @@ overhead; the chance that an adversary will correctly guess a
 valid hash is acceptably low, given that the OP or OR tear down
 the circuit if they receive a bad hash.
 
+This approach has, however, appeared less robust than we hoped;
+while tagging attacks don't provide more information than an
+end-to-end attacker could get through passive correlation attacks,
+they succeed more quickly. Even that isn't such a big deal, were
+it not for a class of attacks that become possible if an attacker
+can detect non-corelatable circuits early and kill them (see
+\ref{???XXXsomewhere-in-attacks-and-defenses}).  We are therefore looking
+into improved constructions for integrity, especially ones based
+on wide-block ciphers.  We hope to also take the opportunity to
+move the authentication mechanism away from the moribund SHA-1.
+
 \subsection{Rate limiting and fairness}
 \label{subsec:rate-limit}
 
@@ -1348,9 +1352,10 @@ cell only when the number of bytes pending to be flushed is
 under some threshold (currently 10 cells' worth).
 % I don't believe that the numbers are 1000 and 100 any more. Must check -NM
 
-These arbitrarily chosen parameters seem to give tolerable
-throughput and delay; see Section~\ref{sec:in-the-wild}.
-% The above paragraph has not held up over time -NM
+These arbitrarily chosen parameters give tolerable but not great
+throughput and delay; see Section~\ref{sec:in-the-wild}. See also
+Section~\ref{????:how-to-really-ratelim} for discussion of future
+work directions on the topic.
 
 \section{Rendezvous Points and hidden services}
 \label{sec:rendezvous}
@@ -1405,9 +1410,6 @@ community finds objectionable, or if Bob's service tends to get
 attacked by network vandals).  The extra level of indirection
 also allows Bob to respond to some requests and ignore others.
 
-% Mention that the list of introduction points can now be encrypted. -NM
-% Mention user authentication? -NM
-% Believed done -SJM
 
 \subsection{Rendezvous points in Tor}
 
@@ -1481,7 +1483,7 @@ points available. Bob could also give secret public keys for
 consulting the lookup service. All of these approaches limit
 exposure even when some selected users collude in the DoS\@.
 
-% Thiss whole section is dated in ways I don't know off the top of my head.
+% Thiss whole section may be dated in ways I don't know off the top of my head.
 % Gotta review the protocol revisions over the years. -NM
 
 
@@ -1501,15 +1503,12 @@ remains a SOCKS proxy.  We encode all of the necessary
 information into the fully qualified domain name (FQDN) Alice
 uses when establishing her connection. Location-hidden services
 use a virtual top level domain called {\tt .onion}: thus
-hostnames take the form {\tt x.y.onion} where {\tt x} is the
-authorization cookie and {\tt y} encodes the hash of the public
+hostnames take the form {\tt y.onion} where
+\tt y} encodes the hash of the public
 key. Alice's onion proxy examines addresses; if they're destined
 for a hidden server, it decodes the key and starts the
 rendezvous as described above.
 
-% Authorization cookies never got built, right? it turns out that
-% ``x.y.onion'' as a format for conveying them is a bad idea, due to the
-% referer headers and stuff like that -NM
 
 \subsection{Previous rendezvous work}