aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2007-02-23 06:50:36 +0000
committerNick Mathewson <nickm@torproject.org>2007-02-23 06:50:36 +0000
commit2bd71aa5f1af38cbd65a5c4835dc298964b447d4 (patch)
tree8f7917daeb7590b9bd41283df34767d0f8f6c858 /doc
parenta98efbf285e95b0fa547639b795d14b6e6ca436d (diff)
downloadtor-2bd71aa5f1af38cbd65a5c4835dc298964b447d4.tar
tor-2bd71aa5f1af38cbd65a5c4835dc298964b447d4.tar.gz
r12296@Kushana: nickm | 2007-02-23 01:50:25 -0500
Add a motivation section to proposal 105. svn:r9620
Diffstat (limited to 'doc')
-rw-r--r--doc/spec/proposals/105-handshake-revision.txt38
1 files changed, 38 insertions, 0 deletions
diff --git a/doc/spec/proposals/105-handshake-revision.txt b/doc/spec/proposals/105-handshake-revision.txt
index 38ecc2180..d68cac66d 100644
--- a/doc/spec/proposals/105-handshake-revision.txt
+++ b/doc/spec/proposals/105-handshake-revision.txt
@@ -15,6 +15,44 @@ Overview:
This is an open proposal.
+Motivation:
+
+ Our *current* approach to versioning the Tor protocol(s) has been as
+ follows:
+ - All changes must be backward compatible.
+ - It's okay to add new cell types, if they would be ignored by previous
+ versions of Tor.
+ - It's okay to add new data elements to cells, if they would have been
+ ignored by previous versions of Tor.
+ - For forward compatibility, Tor must ignore cell types it doesn't
+ recognize, and ignore data in those cells it doesn't expect.
+ - Clients can inspect the version of Tor declared in the platform line
+ of a router's descriptor, and use that to learn whether a server
+ supports a given feature. Servers, however, aren't assumed to all
+ know about each other, and so don't know the version of who they're
+ talking to.
+
+ This system has these problems:
+ - It's very hard to change fundamental aspects of the protocol, like the
+ cell format, the link protocol, any of the various encryption schemes,
+ and so on.
+ - The router-to-router link protocol has remained more-or-less frozen
+ for a long time, since we can't easily have an OR use new features
+ unless it knows the other OR will understand them.
+
+ We need to resolve these problems because:
+ - Our cipher suite is showing its age: SHA1/AES128/RSA1024/DH1024 will
+ not seem like the best idea for all time.
+ - There are many ideas circulating for multiple cell sizes; while it's
+ not obvious whether these are safe, we can't do them at all without a
+ mechanism to permit them.
+ - There are many ideas circulating for alternative cell relay rules:
+ they don't work unless they can coexist in the current network.
+ - If our protocol changes a lot, it's hard to describe any coherent
+ version of it: we need to say "the version that Tor versions W through
+ X use when talking to versions Y through Z". This makes analysis
+ harder.
+
Proposal:
1.0. Version numbers