r11521@catbus: nickm | 2007-01-26 01:07:55 -0500

 Split tor-spec-v2 and dir-voting into component proposals.


svn:r9417

7 files changed, 270 insertions, 123 deletions

diff --git a/doc/spec/proposals/098-todo.txt b/doc/spec/proposals/098-todo.txt
new file mode 100644
index 000000000..40c2ca542
--- /dev/null
+++ b/doc/spec/proposals/098-todo.txt
@@ -0,0 +1,62 @@
+
+                      Proposals that should be written
+
+
+For protocol version 2:
+
+  - Fix onionskin handshake scheme to be more mainstream, less nutty.
+    Can we just do
+        E(HMAC(g^x), g^x) rather than just E(g^x) ?
+    No, that has the same flaws as before. We should send
+        E(g^x, C) with random C and expect g^y, HMAC_C(K=g^xy).
+    Better ask Ian; probably Stephen too.
+  - Versioned CREATE and friends
+  - Length on CREATE and friends
+  - Versioning on circuits
+  - Versioning on create cells
+  - SHA1 is showing its age
+  - Not being able to upgrade ciphersuites or increase key lengths is
+    lame.
+
+Any time:
+
+  - REASON_CONNECTFAILED should include an IP.
+  - Spec should incorporate some prose from tor-design to be more readable.
+  - Spec when we should rotate which keys
+
+
+Things that should change...
+
+B.1. ... but which will require backward-incompatible change
+
+  - Circuit IDs should be longer.
+  - IPv6 everywhere.
+  - Maybe, keys should be longer.
+    - Maybe, key-length should be adjustable.  How to do this without
+      making anonymity suck?
+  - Drop backward compatibility.
+  - We should use a 128-bit subgroup of our DH prime.
+  - Handshake should use HMAC.
+  - Multiple cell lengths.
+  - Ability to split circuits across paths (If this is useful.)
+  - SENDME windows should be dynamic.
+
+  - Directory
+     - Stop ever mentioning socks ports
+
+B.1. ... and that will require no changes
+
+   - Mention multiple addr/port combos
+   - Advertised outbound IP?
+   - Migrate streams across circuits.
+
+B.2. ... and that we have no idea how to do.
+
+   - UDP (as transport)
+   - UDP (as content)
+   - Use a better AES mode that has built-in integrity checking,
+     doesn't grow with the number of hops, is not patented, and
+     is implemented and maintained by smart people.
+
+Let onion keys be not just RSA but maybe DH too. for the reply onion
+design.
diff --git a/doc/spec/proposals/099-misc.txt b/doc/spec/proposals/099-misc.txt
new file mode 100644
index 000000000..52f60e266
--- /dev/null
+++ b/doc/spec/proposals/099-misc.txt
@@ -0,0 +1,13 @@
+
+                           Miscellaneous proposals
+
+
+1. Directory compression.
+
+  Gzip would be easier to work with than zlib; bzip2 would result in smaller
+  data lengths.  [Concretely, we're looking at about 10-15% space savings at
+  the expense of 3-5x longer compression time for using bzip2.]  Doing
+  on-the-fly gzip requires zlib 1.2 or later; doing bzip2 requires bzlib.
+  Pre-compressing status documents in multiple formats would force us to use
+  more memory to hold them.
+
diff --git a/doc/spec/proposals/101-dir-voting.txt b/doc/spec/proposals/101-dir-voting.txt
index 490970185..1a7e77677 100644
--- a/doc/spec/proposals/101-dir-voting.txt
+++ b/doc/spec/proposals/101-dir-voting.txt
@@ -253,112 +253,8 @@ by the authorities. -RD]
   post to every other.  The "download if no copy has been received" mechanism
   exists only as a fallback.
 
-3.2. Dropping "opt".
-
-  The "opt" keyword in Tor's directory formats was originally intended to
-  mean, "it is okay to ignore this entry if you don't understand it"; the
-  default behavior has been "discard a routerdesc if it contains entries you
-  don't recognize."
-
-  But so far, every new flag we have added has been marked 'opt'.  It would
-  probably make sense to change the default behavior to "ignore unrecognized
-  fields", and add the statement that clients SHOULD ignore fields they don't
-  recognize.  As a meta-principle, we should say that clients and servers
-  MUST NOT have to understand new fields in order to use directory documents
-  correctly.
-
-  Of course, this will make it impossible to say, "The format has changed a
-  lot; discard this quietly if you don't understand it." We could do that by
-  adding a version field.
-
-3.3. Multilevel keys.
-
-  Replacing a directory authority's identity key in the event of a compromise
-  would be tremendously annoying.  We'd need to tell every client to switch
-  their configuration, or update to a new version with an uploaded list.  So
-  long as some weren't upgraded, they'd be at risk from whoever had
-  compromised the key.
-
-  With this in mind, it's a shame that our current protocol forces us to
-  store identity keys unencrypted in RAM.  We need some kind of signing key
-  stored unencrypted, since we need to generate new descriptors/directories
-  and rotate link and onion keys regularly.  (And since, of course, we can't
-  ask server operators to be on-hand to enter a passphrase every time we
-  want to rotate keys or sign a descriptor.)
-
-  The obvious solution seems to be to have a signing-only key that lives
-  indefinitely (months or longer) and signs descriptors and link keys, and a
-  separate identity key that's used to sign the signing key.  Tor servers
-  could run in one of several modes:
-    1. Identity key stored encrypted.  You need to pick a passphrase when
-       you enable this mode, and re-enter this passphrase every time you
-       rotate the signing key.
-    1'. Identity key stored separate.  You save your identity key to a
-       floppy, and use the floppy when you need to rotate the signing key.
-    2. All keys stored unencrypted.  In this case, we might not want to even
-       *have* a separate signing key.  (We'll need to support no-separate-
-       signing-key mode anyway to keep old servers working.)
-    3. All keys stored encrypted. You need to enter a passphrase to start
-       Tor.
-  (Of course, we might not want to implement all of these.)
-
-  Case 1 is probably most usable and secure, if we assume that people don't
-  forget their passphrases or lose their floppies.  We could mitigate this a
-  bit by encouraging people to PGP-encrypt their passphrases to themselves,
-  or keep a cleartext copy of their secret key secret-split into a few
-  pieces, or something like that.
-
-  Migration presents another difficulty, especially with the authorities.  If
-  we use the current set of identity keys as the new identity keys, we're in
-  the position of having sensitive keys that have been stored on
-  media-of-dubious-encryption up to now.  Also, we need to keep old clients
-  (who will expect descriptors to be signed by the identity keys they know
-  and love, and who will not understand signing keys) happy.
-
-  I'd enumerate designs here, but I'm hoping that somebody will come up with
-  a better one, so I'll try not to prejudice them with more ideas yet.
-
-  Oh, and of course, we'll want to make sure that the keys are
-  cross-certified. :)
-
-  Ideas? -NM
-
-3.4. Long and short descriptors
-
-  Some of the costliest fields in the current directory protocol are ones
-  that no client actually uses.  In particular, the "read-history" and
-  "write-history" fields are used only by the authorities for monitoring the
-  status of the network.  If we took them out, the size of a compressed list
-  of all the routers would fall by about 60%.  (No other disposable field
-  would save more than 2%.)
-
-  One possible solution here is that routers should generate and upload a
-  short-form and long-form descriptor.  Only the short-form descriptor should
-  ever be used by anybody for routing.  The long-form descriptor should be
-  used only for analytics and other tools.  (If we allowed people to route with
-  long descriptors, we'd have to ensure that they stayed in sync with the
-  short ones somehow.)  We can ensure that the short descriptors are used by
-  only recommending those in the network statuses.
-
-  Another possible solution would be to drop these fields from descriptors,
-  and have them uploaded as a part of a separate "bandwidth report" to the
-  authorities.  This could help prevent the mistake of using long descriptors
-  in the place of short ones.
-
-  Thoughts? -NM
-
-3.5. Compression
-
-  Gzip would be easier to work with than zlib; bzip2 would result in smaller
-  data lengths.  [Concretely, we're looking at about 10-15% space savings at
-  the expense of 3-5x longer compression time for using bzip2.]  Doing
-  on-the-fly gzip requires zlib 1.2 or later; doing bzip2 requires bzlib.
-  Pre-compressing status documents in multiple formats would force us to use
-  more memory to hold them.
-
 4. Migration
 
-  For directory voting:
      * It would be cool if caches could get ready to download consensus
        status docs, verify enough signatures, and serve them now.  That way
        once stuff works all we need to do is upgrade the authorities.  Caches
@@ -367,22 +263,3 @@ by the authorities. -RD]
        off very quickly from downloading consensus docs until they're
        actually implemented.
 
-  For dropping the "opt" requirement:
-     * stopped requiring it as of 0.1.2.5-alpha.  Stop generating it once
-       earlier formats are obsolete.
-
-  For multilevel keys:
-     * no idea
-
-  For long/short descriptors:
-     * In 0.1.2.x:
-       * Authorities should accept both, now, and silently drop short
-         descriptors.
-       * Routers should upload both once authorities accept them.
-       * There should be a "long descriptor" url and the current "normal" URL.
-         Authorities should serve long descriptors from both URLs.
-     * Once tools that want long descriptors support fetching them from the
-       "long descriptor" URL:
-       * Have authorities remember short descriptors, and serve them from the
-         'normal' URL.
-
diff --git a/doc/spec/proposals/102-drop-opt.txt b/doc/spec/proposals/102-drop-opt.txt
new file mode 100644
index 000000000..bc1d52f68
--- /dev/null
+++ b/doc/spec/proposals/102-drop-opt.txt
@@ -0,0 +1,26 @@
+
+                    Drop "opt" from the directory format.
+
+  The "opt" keyword in Tor's directory formats was originally intended to
+  mean, "it is okay to ignore this entry if you don't understand it"; the
+  default behavior has been "discard a routerdesc if it contains entries you
+  don't recognize."
+
+  But so far, every new flag we have added has been marked 'opt'.  It would
+  probably make sense to change the default behavior to "ignore unrecognized
+  fields", and add the statement that clients SHOULD ignore fields they don't
+  recognize.  As a meta-principle, we should say that clients and servers
+  MUST NOT have to understand new fields in order to use directory documents
+  correctly.
+
+  Of course, this will make it impossible to say, "The format has changed a
+  lot; discard this quietly if you don't understand it." We could do that by
+  adding a version field.
+
+
+Status:
+
+     * We stopped requiring it as of 0.1.2.5-alpha.  We'll stop generating it
+       once earlier formats are obsolete.
+
+
diff --git a/doc/spec/proposals/103-multilevel-keys.txt b/doc/spec/proposals/103-multilevel-keys.txt
new file mode 100644
index 000000000..554ca6520
--- /dev/null
+++ b/doc/spec/proposals/103-multilevel-keys.txt
@@ -0,0 +1,54 @@
+
+           Splitting identity key from regularly-used signing key.
+
+
+
+  Replacing a directory authority's identity key in the event of a compromise
+  would be tremendously annoying.  We'd need to tell every client to switch
+  their configuration, or update to a new version with an uploaded list.  So
+  long as some weren't upgraded, they'd be at risk from whoever had
+  compromised the key.
+
+  With this in mind, it's a shame that our current protocol forces us to
+  store identity keys unencrypted in RAM.  We need some kind of signing key
+  stored unencrypted, since we need to generate new descriptors/directories
+  and rotate link and onion keys regularly.  (And since, of course, we can't
+  ask server operators to be on-hand to enter a passphrase every time we
+  want to rotate keys or sign a descriptor.)
+
+  The obvious solution seems to be to have a signing-only key that lives
+  indefinitely (months or longer) and signs descriptors and link keys, and a
+  separate identity key that's used to sign the signing key.  Tor servers
+  could run in one of several modes:
+    1. Identity key stored encrypted.  You need to pick a passphrase when
+       you enable this mode, and re-enter this passphrase every time you
+       rotate the signing key.
+    1'. Identity key stored separate.  You save your identity key to a
+       floppy, and use the floppy when you need to rotate the signing key.
+    2. All keys stored unencrypted.  In this case, we might not want to even
+       *have* a separate signing key.  (We'll need to support no-separate-
+       signing-key mode anyway to keep old servers working.)
+    3. All keys stored encrypted. You need to enter a passphrase to start
+       Tor.
+  (Of course, we might not want to implement all of these.)
+
+  Case 1 is probably most usable and secure, if we assume that people don't
+  forget their passphrases or lose their floppies.  We could mitigate this a
+  bit by encouraging people to PGP-encrypt their passphrases to themselves,
+  or keep a cleartext copy of their secret key secret-split into a few
+  pieces, or something like that.
+
+  Migration presents another difficulty, especially with the authorities.  If
+  we use the current set of identity keys as the new identity keys, we're in
+  the position of having sensitive keys that have been stored on
+  media-of-dubious-encryption up to now.  Also, we need to keep old clients
+  (who will expect descriptors to be signed by the identity keys they know
+  and love, and who will not understand signing keys) happy.
+
+  I'd enumerate designs here, but I'm hoping that somebody will come up with
+  a better one, so I'll try not to prejudice them with more ideas yet.
+
+  Oh, and of course, we'll want to make sure that the keys are
+  cross-certified. :)
+
+  Ideas? -NM
diff --git a/doc/spec/proposals/104-short-descriptors.txt b/doc/spec/proposals/104-short-descriptors.txt
new file mode 100644
index 000000000..c170c641d
--- /dev/null
+++ b/doc/spec/proposals/104-short-descriptors.txt
@@ -0,0 +1,41 @@
+
+                      Long and Short Router Descriptors
+
+
+  Some of the costliest fields in the current directory protocol are ones
+  that no client actually uses.  In particular, the "read-history" and
+  "write-history" fields are used only by the authorities for monitoring the
+  status of the network.  If we took them out, the size of a compressed list
+  of all the routers would fall by about 60%.  (No other disposable field
+  would save more than 2%.)
+
+  One possible solution here is that routers should generate and upload a
+  short-form and long-form descriptor.  Only the short-form descriptor should
+  ever be used by anybody for routing.  The long-form descriptor should be
+  used only for analytics and other tools.  (If we allowed people to route with
+  long descriptors, we'd have to ensure that they stayed in sync with the
+  short ones somehow.)  We can ensure that the short descriptors are used by
+  only recommending those in the network statuses.
+
+  Another possible solution would be to drop these fields from descriptors,
+  and have them uploaded as a part of a separate "bandwidth report" to the
+  authorities.  This could help prevent the mistake of using long descriptors
+  in the place of short ones.
+
+  Thoughts? -NM
+
+Migration:
+
+  For long/short descriptors:
+     * In 0.1.2.x:
+       * Authorities should accept both, now, and silently drop short
+         descriptors.
+       * Routers should upload both once authorities accept them.
+       * There should be a "long descriptor" url and the current "normal" URL.
+         Authorities should serve long descriptors from both URLs.
+     * Once tools that want long descriptors support fetching them from the
+       "long descriptor" URL:
+       * Have authorities remember short descriptors, and serve them from the
+         'normal' URL.
+
+
diff --git a/doc/spec/proposals/105-handshake-revision.txt b/doc/spec/proposals/105-handshake-revision.txt
new file mode 100644
index 000000000..b718ec441
--- /dev/null
+++ b/doc/spec/proposals/105-handshake-revision.txt
@@ -0,0 +1,74 @@
+
+                  Version negotiation for the Tor protocol.
+
+
+1.0. Version numbers
+
+   The node-to-node TLS-based "OR connection" protocol and the multi-hop
+   "circuit" protocol are versioned quasi-independently.  (Certain versions
+   of the circuit protocol may require a minimum version of the connection
+   protocol to be used.)
+
+   Version numbers are incremented for backward-incompatible protocol changes
+   only.  Backward-compatible changes are generally implemented by adding
+   additional fields to existing structures; implementations MUST ignore
+   fields they do not expect.
+
+
+2.1. VERSIONS cells
+
+   When a Tor connection is established, both parties normally send a
+   VERSIONS cell before sending any other cells.  (But see below.)
+
+         NumVersions            [1 byte]
+         Versions               [NumVersions bytes]
+
+   "Versions" is a sequence of NumVersions link connection protocol versions,
+   each one byte long.  Parties should list all of the versions which they
+   are able and willing to support.  Parties can only communicate if they
+   have some connection protocol version in common.
+
+   Version 0.1.x.y-alpha and earlier don't understand VERSIONS cells,
+   and therefore don't support version negotiation.  Thus, waiting until
+   the other side has sent a VERSIONS cell won't work for these servers:
+   if they send no cells back, it is impossible to tell whether they
+   have sent a VERSIONS cell that has been stalled, or whether they have
+   dropped our own VERSIONS cell as unrecognized.  Thus, immediately after
+   a TLS connection has been established, the parties check whether the
+   other side has an obsolete certificate (organizationName equal to "Tor"
+   or "TOR").  If the other party presented an obsolete certificate,
+   we assume a v1 connection.  Otherwise, both parties send VERSIONS
+   cells listing all their supported versions.  Upon receiving the
+   other party's VERSIONS cell, the implementation begins using the
+   highest-valued version common to both cells.  If the first cell from
+   the other party is _not_ a VERSIONS cell, we assume a v1 protocol.
+
+   Implementations MUST discard cells that are not the first cells sent on a
+   connection.
+
+2.2. MITM-prevention and time checking
+
+   If we negotiate a v2 connection or higher, the first cell we send SHOULD
+   be a NETINFO cell.  Implementations SHOULD NOT send NETINFO cells at other
+   times.
+
+   A NETINFO cell contains:
+         Timestamp              [4 bytes]
+         This OR's address      [variable]
+         Other OR's address     [variable]
+
+   Timestamp is the OR's current Unix time, in seconds since the epoch.  If
+   an implementation receives time values from many validated ORs that
+   indicate that its clock is skewed, it SHOULD try to warn the
+   administrator.
+
+   Each address contains Type/Length/Value as used in Section 6.4.  The first
+   address is the address of the interface the party sending the VERSIONS cell
+   used to connect to or accept connections from the other -- we include it
+   to block a man-in-the-middle attack on TLS that lets an attacker bounce
+   traffic through his own computers to enable timing and packet-counting
+   attacks.
+
+   The second address is the one that the party sending the VERSIONS cell
+   believes the other has -- it can be used to learn what your IP address
+   is if you have no other hints.