add new proposal 148-uniform-client-end-reason.txt

svn:r15612

2 files changed, 60 insertions, 0 deletions

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index e13b32c..df186fc 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -70,6 +70,7 @@ Proposals by number:
 145  Separate "suitable as a guard" from "suitable as a new guard" [OPEN]
 146  Add new flag to reflect long-term stability [OPEN]
 147  Eliminate the need for v2 directories in generating v3 directories [OPEN]
+148  Stream end reasons from the client side should be uniform [OPEN]
 
 
 Proposals by status:
@@ -93,6 +94,7 @@ Proposals by status:
    145  Separate "suitable as a guard" from "suitable as a new guard"
    146  Add new flag to reflect long-term stability
    147  Eliminate the need for v2 directories in generating v3 directories
+   148  Stream end reasons from the client side should be uniform
  NEEDS-REVISION:
    110  Avoiding infinite length circuits
    117  IPv6 exits
diff --git a/proposals/148-uniform-client-end-reason.txt b/proposals/148-uniform-client-end-reason.txt
new file mode 100644
index 0000000..0ccfcd2
--- /dev/null
+++ b/proposals/148-uniform-client-end-reason.txt
@@ -0,0 +1,58 @@
+Filename: 148-uniform-client-end-reason.txt
+Title: Stream end reasons from the client side should be uniform
+Version: $Revision$
+Last-Modified: $Date$
+Author: Roger Dingledine
+Created: 2-Jul-2008
+Status: Open
+
+Overview
+
+  When a stream closes before it's finished, the end relay cell that's
+  sent includes an "end stream reason" to tell the other end why it
+  closed. It's useful for the exit relay to send a reason to the client,
+  so the client can choose a different circuit, inform the user, etc. But
+  there's no reason to include it from the client to the exit relay,
+  and in some cases it can even harm anonymity.
+
+  We should pick a single reason for the client-to-exit-relay direction
+  and always just send that.
+
+Motivation
+
+  Back when I first deployed the Tor network, it was useful to have
+  the Tor relays learn why a stream closed, so I could debug both ends
+  of the stream at once. Now that streams have worked for many years,
+  there's no need to continue telling the exit relay whether the client
+  gave up on a stream because of "timeout" or "misc" or what.
+
+  Then in Tor 0.2.0.28-rc, I fixed this bug:
+    - Fix a bug where, when we were choosing the 'end stream reason' to
+      put in our relay end cell that we send to the exit relay, Tor
+      clients on Windows were sometimes sending the wrong 'reason'. The
+      anonymity problem is that exit relays may be able to guess whether
+      the client is running Windows, thus helping partition the anonymity
+      set. Down the road we should stop sending reasons to exit relays,
+      or otherwise prevent future versions of this bug.
+
+  It turned out that non-Windows clients were choosing their reason
+  correctly, whereas Windows clients were potentially looking at errno
+  wrong and so always choosing 'misc'.
+
+  I fixed that particular bug, but I think we should prevent future
+  versions of the bug too.
+
+  (We already fixed it so *circuit* end reasons don't get sent from
+  the client to the exit relay. But we appear to be have skipped over
+  stream end reasons thus far.)
+
+Design:
+
+  One option would be to no longer include any 'reason' field in end
+  relay cells. But that would introduce a partitioning attack ("users
+  running the old version" vs "users running the new version").
+
+  Instead I suggest that clients all switch to sending the "misc" reason,
+  like most of the Windows clients currently do and like the non-Windows
+  clients already do sometimes.
+