[tor-commits] [tor-browser-spec/master] Mention using SPDY at exits.

[mikeperry at torproject.org]

commit 7d906d2a0d80eb6d198e2cf7a757cfe98b5c3eb8
Author: Mike Perry <mikeperry-git at fscked.org>
Date:   Mon Mar 11 19:16:16 2013 -0700

    Mention using SPDY at exits.
---
 docs/design/design.xml |   23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/docs/design/design.xml b/docs/design/design.xml
index 1bb33aa..68f899c 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -23,7 +23,7 @@
      <address><email>sjmurdoch#torproject org</email></address>
     </affiliation>
    </author>
-   <pubdate>March 8 2013</pubdate>
+   <pubdate>March 11, 2013</pubdate>
  </articleinfo>
 
 <!--
@@ -783,11 +783,12 @@ to manipulate at low cost.
      </para>
      <para>
 
-In fact, the ocean of Tor Internet activity (at least, when compared to a lab
-setting) makes it a certainty that an adversary attempting examine large
-amounts of Tor traffic will ultimately be overwhelmed by false positives (even
-after making heavy tradeoffs on the ROC curve to minimize false positives to
-below 0.01%). This problem is known in the IDS literature as the <ulink
+To make matters worse for a real-world adversary, the ocean of Tor Internet
+activity (at least, when compared to a lab setting) makes it a certainty that
+an adversary attempting examine large amounts of Tor traffic will ultimately
+be overwhelmed by false positives (even after making heavy tradeoffs on the
+ROC curve to minimize false positives to below 0.01%). This problem is known
+in the IDS literature as the <ulink
 url="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf">Base Rate
 Fallacy</ulink>, and it is the primary reason that anomaly and activity
 classification-based IDS and antivirus systems have failed to materialize in
@@ -1841,7 +1842,8 @@ network overhead. In the no-overhead category, we have <ulink
 url="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf">HTTPOS</ulink> and
 <ulink
 url="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting">better
-use of HTTP pipelining and/or SPDY</ulink>. In the tunable/low-overhead
+use of HTTP pipelining and/or SPDY</ulink>. 
+In the tunable/low-overhead
 category, we have <ulink
 url="http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf">Adaptive
 Padding</ulink> and <ulink url="http://www.cs.sunysb.edu/~xcai/fp.pdf">
@@ -1865,7 +1867,12 @@ pipelining may simply return error codes for successive requests, effectively
 forcing the browser into non-pipelined behavior. Firefox also has code to back
 off and reduce or eliminate the pipeline if this happens. These
 shortcomings and fallback behaviors are the primary reason that Google
-developed SPDY as opposed simply extending HTTP to improve pipelining.
+developed SPDY as opposed simply extending HTTP to improve pipelining. It
+turns out that we could actually deploy exit-side proxies that allow us to
+<ulink
+url="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-using-spdy.txt">use
+SPDY from the client to the exit node</ulink>. This would make our defense not
+only free, but one that actually <emphasis>improves</emphasis> performance.
 
      </para>
      <para>