diff options
author | Nick Mathewson <nickm@torproject.org> | 2007-02-23 06:50:36 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2007-02-23 06:50:36 +0000 |
commit | 7993ab123ad38672038cb53f16c393e858297e74 (patch) | |
tree | 2f447f643ed276721e108622294dbc042e98da18 /proposals/105-handshake-revision.txt | |
parent | c670defa1d386d00b22b08f07e5751799a944a11 (diff) | |
download | torspec-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.txt | 38 |
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 |