# [or-cvs] r18878: {projects} flesh out section 6 (projects/performance)

arma at seul.org arma at seul.org
Wed Mar 11 10:38:01 UTC 2009

Author: arma
Date: 2009-03-11 06:38:01 -0400 (Wed, 11 Mar 2009)
New Revision: 18878

Modified:
projects/performance/performance.tex
Log:
flesh out section 6

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-11 10:21:37 UTC (rev 18877)
+++ projects/performance/performance.tex	2009-03-11 10:38:01 UTC (rev 18878)
@@ -1462,23 +1462,38 @@
{\bf Plan}: Overall, it seems like a risky move, but with potentially
quite a good payoff. I'm not convinced either way.

-\section{Network overhead too high for modem users}
+\section{The network overhead is still too high for modem users}

+Even if we resolve all the other pieces of the performance question,
+there still remain some challenges posed uniquely by users with extremely
+low bandwidth -- for example, users on modems or cell phones. We need
+to optimize the Tor protocols so they are efficient enough that Tor can
+be practical in this situation too.
+

-start building connections.
-The current directory format (version 3) already gives a substantial
-reduction in size.
-However, more improvements are possible and Proposal 158, which further
-reduces the directory overhead, is scheduled to be deployed in the Tor
-0.2.2.x series.
-Further background on directory overhead progress is given in our blog
+overhead, both for bootstrapping and maintenance. Our
+blog post on the topic provides background and

-\subsection{TLS overhead also can be improved}
+Proposal 158, which further reduces the directory overhead, is scheduled
+to be deployed in the Tor 0.2.2.x series.\footnote{\url{https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt}}

+{\bf Impact}: Low for normal users, high for low-bandwidth users.
+
+{\bf Effort}: Medium, but we're already a lot of the way through it.
+
+{\bf Risk}: Low.
+
+{\bf Plan}: Once we roll out proposal 158, I think we'll be in good
+shape for a while. The next directory overhead challenge will be in
+splintering the network, but first we must get enough relays that the
+step is needed.
+
+\subsection{Our TLS overhead can also be improved}
+
OpenSSL will, by default, insert an empty TLS application record before
any one which contains data.
This is to prevent an attack, by which someone who has partial control
@@ -1510,25 +1525,33 @@
Of course, the empty application record was inserted for a reason --
to prevent an attack on the CBC mode of operation used by TLS, so before
removing it we must be confident the attack does not apply to Tor.
-Ben Laurie (one of the OpenSSL developers), concluded that in his
+Ben Laurie (one of the OpenSSL developers) concluded that in his
opinion Tor could safely remove the insertion of empty TLS application
records~\cite{tls-empty-record}.
-I was able to come up with only certificational weaknesses (discussed
+Steven was able to come up with only certificational weaknesses (discussed
in the above analysis), which are expensive to exploit and give little
information to the attacker.

-To be successful, the attacker must have full control of the plaintext
-application record before the one he wishes to guess.
-Tor makes this difficult because all cells where the payload is controlled
-by the attacker are prepended with a two byte circuit ID, unknown to
-the attacker.
-Also, because the majority of cells sent in Tor are encrypted by a key
-not known by the attacker, the probability that an attacker can guess
-what a cell might be is extremely small.
-The exception is a padding cell, which has no circuit ID and a zero
-other than as a periodic keep-alive.
+%To be successful, the attacker must have full control of the plaintext
+%application record before the one he wishes to guess.
+%Tor makes this difficult because all cells where the payload is controlled
+%by the attacker are prepended with a two byte circuit ID, unknown to
+%the attacker.
+%Also, because the majority of cells sent in Tor are encrypted by a key
+%not known by the attacker, the probability that an attacker can guess
+%what a cell might be is extremely small.
+%The exception is a padding cell, which has no circuit ID and a zero
+%other than as a periodic keep-alive.

+{\bf Impact}: Low.
+
+{\bf Effort}: Low.
+
+{\bf Risk}: Medium, since our initial analysis might be wrong.
+
+{\bf Plan}: Do it in the Tor 0.2.2.x or 0.2.3.x timeframe. Not critical.
+
%\subsection{Hibernating relays shouldn't be listed as Running}

%we are giving Running flags to hibernating relays. if we stop giving