From b6d2ffa5201a207cc4d7401cf5f88f16cf203406 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 2 Mar 2007 20:00:33 +0000 Subject: r12374@Kushana: nickm | 2007-03-02 13:12:09 -0500 Try to nail down versions and version negotiation more thoroughly. Document some issues and ideas. Try to make things more extensible. svn:r9713 --- proposals/105-handshake-revision.txt | 150 ++++++++++++++++++++++++++++++++--- 1 file changed, 139 insertions(+), 11 deletions(-) (limited to 'proposals/105-handshake-revision.txt') diff --git a/proposals/105-handshake-revision.txt b/proposals/105-handshake-revision.txt index d68cac6..117c150 100644 --- a/proposals/105-handshake-revision.txt +++ b/proposals/105-handshake-revision.txt @@ -15,7 +15,7 @@ Overview: This is an open proposal. -Motivation: +Motivation: Tor versions Our *current* approach to versioning the Tor protocol(s) has been as follows: @@ -46,34 +46,80 @@ Motivation: - 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. + - There are many ideas circulating for alternative circuit building and + 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. +Motivation: Preventing MITM attacks + + TLS prevents a man-in-the-middle attacker from reading or changing the + contents of a communication. It does not, however, prevent such an + attacker from observing timing information. Since timing attacks are some + of the most effective against low-latency anonymity nets like Tor, we + should take more care to make sure that once we're not only talking to who + we think we're talking to, but that we're using the network path we + believe we're using. + +Motivation: Signed clock information + + It's very useful for Tor instances to know how skewed they are relative + to one another. The only way to find out currently has been to download + directory information, and check the Date header--but this is not + authenticated, and hence subject to modification on the wire. Using + BEGIN_DIR to create an authenticated directory stream through an existing + circuit is better, but only works when the other party serves directory + information. + Proposal: 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 + "circuit" protocol are versioned quasi-independently. + + Of course, some dependencies will continue to exist: Certain versions of the circuit protocol may require a minimum version of the connection - protocol to be used.) + protocol to be used. The connection protocol affects: + - Initial connection setup, link encryption, transport guarantees, + etc. + - The allowable set of cell commands + - Allowable formats for cells. + + The circuit protocol determines: + - How circuits are established and maintained + - How cells are decrypted and relayed + - How streams are established and maintained. 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. - + fields they do not expect. Unused portions of cells MUST be set to zero. + + Though versioning the protocol will make it easier to maintain backward + compatibility with older versions of Tor, we will nevertheless continue to + periodically drop support for older protocol, + - to keep the implementation from growing without bound, + - to limit the maintenance burden of patching bugs in obsolete Tors, + - to limit the testing burden of verifying that many old protocol + versions continue to be implemented properly, and + - to limit the exposure of the network to protocol versions that are + expensive to support. + + The Tor protocol as implemented through the 0.1.2.x Tor series will be + called "version 1" in its link protocol and "version 1" in its relay + protocol. Versions of the Tor protocol so old as to be incompatible with + Tor 0.1.2.x 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] + NumVersions [1 byte] Versions [NumVersions bytes] "Versions" is a sequence of NumVersions link connection protocol versions, @@ -94,10 +140,14 @@ Proposal: 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. + the other party has a recognized command, and is _not_ a VERSIONS cell, we + assume a v1 protocol. - Implementations MUST discard cells that are not the first cells sent on a - connection. + Implementations MUST discard VERSIONS cells that are not the first + recognized cells sent on a connection. + + The VERSIONS cell must be sent as a v1 cell (2 bytes of circuitID, 1 + byte of command, 590 bytes of payload). 2.2. MITM-prevention and time checking @@ -125,3 +175,81 @@ Proposal: 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. + +Discussion: Versions versus feature lists + + Many protocols negotiate lists of available features instead of (or in + addition to) protocol versions. While it's possible that some amount of + version negotiation could be supported in a later Tor, we should prefer to + use protocol versions whenever possible, for reasons discussed in + the "Anonymity Loves Company" paper. + +Discussion: Bytes per version, versions per cell + + This document provides for a one-byte count of how many versions a Tor + supports, and allows one byte per version. Thus, it can only support only + 254 more versions of the protocol beyond the unallocated v0 and the + current v1. If we ever need to split the protocol into 255 incompatible + versions, we've probably screwed up badly somewhere. + + Nevertheless, here are two ways we could support more versions: + - Change the version count to a two-byte field that counts the number of + _bytes_ used, and use a UTF8-style encoding Versions 0 through 127 + take one byte to encode; versions 128 through 2047 take two bytes to + encode, and so on. We wouldn't need to parse any version higher than + 127 right now, since all bytes used to encode higher versions would + have their high bit set. + + We'd still have a limit of 380 simultaneously versions that could be + declared in any version. This is probably okay. + + - Decide that if we need to support more versions, we can add a + MOREVERSIONS cell that gets sent before the VERSIONS cell. The spec + above requires Tors to ignore unrecognized cell types that they get + before the first VERSIONS cell, and still allow version negotiation to + succeed. + +Discussion: Reducing round-trips + + It might be appealing to see if we can cram more information in the + initial VERSIONS cell. For example, the contents of NETINFO will pretty + soon be sent by everybody before any more information is exchanged, but + decoupling them from the version exchange increases round-trips. + + Instead, we could speculatively include handshaking information at + the end of a VERSIONS cell, wrapped in a marker to indicate, "if we wind + up speaking VERSION 2, here's the NETINFO I'll send. Otherwise, ignore + this." This could be extended to opportunistically reduce round trips + when possible for future versions when we guess the versions right. + + Of course, we'd need to be careful about using a feature like this: + - We don't want to include things that are expensive to compute, + like PK signatures or proof-of-work. + - We don't want to speculate as a mobile client it will leak our + experience with the server in question. + +Discussion: Advertising versions in routerdescs and networkstatuses. + + XXXX + +Security issues: + + Client partitioning is the big danger when we introduce new versions; if a + client supports some very unusual set of protocol versions, it will stand + out from others no matter where it goes. If a server supports an unusual + version, it will get a disproportionate amount of traffic from clients who + prefer that version. We can mitigate this somewhat as follows: + + - Do not have clients prefer any protocol version by default until that + version is widespread. + + - Do not multiply protocol versions needlessly. + + - Encourage protocol implementors to implement the same protocol version + sets as some popular version of Tor. + + - Disrecommend very old/unpopular versions of Tor via the directory + authorities' RecommmendedVersions mechanism, even if it is still + technically possible to use them. + + -- cgit v1.2.3-54-g00ecf