aboutsummaryrefslogtreecommitdiff
path: root/proposals/105-handshake-revision.txt
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
commit7993ab123ad38672038cb53f16c393e858297e74 (patch)
tree2f447f643ed276721e108622294dbc042e98da18 /proposals/105-handshake-revision.txt
parentc670defa1d386d00b22b08f07e5751799a944a11 (diff)
downloadtorspec-7993ab123ad38672038cb53f16c393e858297e74.tar.gz
torspec-7993ab123ad38672038cb53f16c393e858297e74.zip
r12296@Kushana: nickm | 2007-02-23 01:50:25 -0500
Add a motivation section to proposal 105. svn:r9620
Diffstat (limited to 'proposals/105-handshake-revision.txt')
-rw-r--r--proposals/105-handshake-revision.txt38
1 files changed, 38 insertions, 0 deletions
diff --git a/proposals/105-handshake-revision.txt b/proposals/105-handshake-revision.txt
index 38ecc21..d68cac6 100644
--- a/proposals/105-handshake-revision.txt
+++ b/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