proposals/098-todo.txt

   1 Filename: 098-todo.txt
   2 Title: Proposals that should be written
   3 Author: Nick Mathewson, Roger Dingledine
   4 Created: 26-Jan-2007
   5 Status: Meta
   6
   7 Overview:
   8
   9    This document lists ideas that various people have had for improving the
  10    Tor protocol.  These should be implemented and specified if they're
  11    trivial, or written up as proposals if they're not.
  12
  13    This is an active document, to be edited as proposals are written and as
  14    we come up with new ideas for proposals.  We should take stuff out as it
  15    seems irrelevant.
  16
  17
  18 For some later protocol version.
  19
  20   - It would be great to get smarter about identity and linkability.
  21     It's not crazy to say, "Never use the same circuit for my SSH
  22     connections and my web browsing."  How far can/should we take this?
  23     See ideas/xxx-separate-streams-by-port.txt for a start.
  24
  25   - Fix onionskin handshake scheme to be more mainstream, less nutty.
  26     Can we just do
  27         E(HMAC(g^x), g^x) rather than just E(g^x) ?
  28     No, that has the same flaws as before. We should send
  29         E(g^x, C) with random C and expect g^y, HMAC_C(K=g^xy).
  30     Better ask Ian; probably Stephen too.
  31
  32   - Length on CREATE and friends
  33
  34   - Versioning on circuits and create cells, so we have a clear path
  35     to improve the circuit protocol.
  36
  37   - SHA1 is showing its age.  We should get a design for upgrading our
  38     hash once the AHS competition is done, or even sooner.
  39
  40   - Not being able to upgrade ciphersuites or increase key lengths is
  41     lame.
  42   - Paul has some ideas about circuit creation; read his PET paper once it's
  43     out.
  44
  45 Any time:
  46
  47   - Some ideas for revising the directory protocol:
  48     - Extend the "r" line in network-status to give a set of buckets (say,
  49       comma-separated) for that router.
  50       - Buckets are deterministic based on IP address.
  51       - Then clients can choose a bucket (or set of buckets) to
  52         download and use.
  53     - We need a way for the authorities to declare that nodes are in a
  54       family.  Also, it kinda sucks that family declarations use O(N^2) space
  55       in the descriptors.
  56   - REASON_CONNECTFAILED should include an IP.
  57   - Spec should incorporate some prose from tor-design to be more readable.
  58   - Spec when we should rotate which keys
  59   - Spec how to publish descriptors less often
  60   - Describe pros and cons of non-deterministic path lengths
  61
  62   - We should use a variable-length path length by default -- 3 +/- some
  63     distribution. Need to think harder about allowing values less than 3,
  64     and there's a tradeoff between having a wide variance and performance.
  65
  66   - Clients currently use certs during TLS.  Is this wise?  It does make it
  67     easier for servers to tell which NATted client is which. We could use a
  68     seprate set of certs for each guard, I suppose, but generating so many
  69     certs could get expensive.  Omitting them entirely would make OP->OR
  70     easier to tell from OR->OR.
  71
  72 Things that should change...
  73
  74 B.1. ... but which will require backward-incompatible change
  75
  76   - Circuit IDs should be longer.
  77   . IPv6 everywhere.
  78   - Maybe, keys should be longer.
  79     - Maybe, key-length should be adjustable.  How to do this without
  80       making anonymity suck?
  81   - Drop backward compatibility.
  82   - We should use a 128-bit subgroup of our DH prime.
  83   - Handshake should use HMAC.
  84   - Multiple cell lengths.
  85   - Ability to split circuits across paths (If this is useful.)
  86   - SENDME windows should be dynamic.
  87
  88   - Directory
  89      - Stop ever mentioning socks ports
  90
  91 B.1. ... and that will require no changes
  92
  93    - Advertised outbound IP?
  94    - Migrate streams across circuits.
  95    - Fix bug 469 by limiting the number of simultaneous connections per IP.
  96
  97 B.2. ... and that we have no idea how to do.
  98
  99    - UDP (as transport)
 100    - UDP (as content)
 101    - Use a better AES mode that has built-in integrity checking,
 102      doesn't grow with the number of hops, is not patented, and
 103      is implemented and maintained by smart people.
 104
 105 Let onion keys be not just RSA but maybe DH too, for Paul's reply onion
 106 design.
 107