doc/spec/proposals/148-uniform-client-end-reason.txt

   1 Filename: 148-uniform-client-end-reason.txt
   2 Title: Stream end reasons from the client side should be uniform
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Roger Dingledine
   6 Created: 2-Jul-2008
   7 Status: Closed
   8 Implemented-In: 0.2.1.9-alpha
   9
  10 Overview
  11
  12   When a stream closes before it's finished, the end relay cell that's
  13   sent includes an "end stream reason" to tell the other end why it
  14   closed. It's useful for the exit relay to send a reason to the client,
  15   so the client can choose a different circuit, inform the user, etc. But
  16   there's no reason to include it from the client to the exit relay,
  17   and in some cases it can even harm anonymity.
  18
  19   We should pick a single reason for the client-to-exit-relay direction
  20   and always just send that.
  21
  22 Motivation
  23
  24   Back when I first deployed the Tor network, it was useful to have
  25   the Tor relays learn why a stream closed, so I could debug both ends
  26   of the stream at once. Now that streams have worked for many years,
  27   there's no need to continue telling the exit relay whether the client
  28   gave up on a stream because of "timeout" or "misc" or what.
  29
  30   Then in Tor 0.2.0.28-rc, I fixed this bug:
  31     - Fix a bug where, when we were choosing the 'end stream reason' to
  32       put in our relay end cell that we send to the exit relay, Tor
  33       clients on Windows were sometimes sending the wrong 'reason'. The
  34       anonymity problem is that exit relays may be able to guess whether
  35       the client is running Windows, thus helping partition the anonymity
  36       set. Down the road we should stop sending reasons to exit relays,
  37       or otherwise prevent future versions of this bug.
  38
  39   It turned out that non-Windows clients were choosing their reason
  40   correctly, whereas Windows clients were potentially looking at errno
  41   wrong and so always choosing 'misc'.
  42
  43   I fixed that particular bug, but I think we should prevent future
  44   versions of the bug too.
  45
  46   (We already fixed it so *circuit* end reasons don't get sent from
  47   the client to the exit relay. But we appear to be have skipped over
  48   stream end reasons thus far.)
  49
  50 Design:
  51
  52   One option would be to no longer include any 'reason' field in end
  53   relay cells. But that would introduce a partitioning attack ("users
  54   running the old version" vs "users running the new version").
  55
  56   Instead I suggest that clients all switch to sending the "misc" reason,
  57   like most of the Windows clients currently do and like the non-Windows
  58   clients already do sometimes.
  59