105-handshake-revision.txt 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325
  1. Filename: 105-handshake-revision.txt
  2. Title: Version negotiation for the Tor protocol.
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Nick Mathewson, Roger Dingledine
  6. Created: Jan 2007
  7. Status: Closed
  8. Implemented-In: 0.2.0.x
  9. Overview:
  10. This document was extracted from a modified version of tor-spec.txt that we
  11. had written before the proposal system went into place. It adds two new
  12. cells types to the Tor link connection setup handshake: one used for
  13. version negotiation, and another to prevent MITM attacks.
  14. This proposal is partially implemented, and partially proceded by
  15. proposal 130.
  16. Motivation: Tor versions
  17. Our *current* approach to versioning the Tor protocol(s) has been as
  18. follows:
  19. - All changes must be backward compatible.
  20. - It's okay to add new cell types, if they would be ignored by previous
  21. versions of Tor.
  22. - It's okay to add new data elements to cells, if they would be
  23. ignored by previous versions of Tor.
  24. - For forward compatibility, Tor must ignore cell types it doesn't
  25. recognize, and ignore data in those cells it doesn't expect.
  26. - Clients can inspect the version of Tor declared in the platform line
  27. of a router's descriptor, and use that to learn whether a server
  28. supports a given feature. Servers, however, aren't assumed to all
  29. know about each other, and so don't know the version of who they're
  30. talking to.
  31. This system has these problems:
  32. - It's very hard to change fundamental aspects of the protocol, like the
  33. cell format, the link protocol, any of the various encryption schemes,
  34. and so on.
  35. - The router-to-router link protocol has remained more-or-less frozen
  36. for a long time, since we can't easily have an OR use new features
  37. unless it knows the other OR will understand them.
  38. We need to resolve these problems because:
  39. - Our cipher suite is showing its age: SHA1/AES128/RSA1024/DH1024 will
  40. not seem like the best idea for all time.
  41. - There are many ideas circulating for multiple cell sizes; while it's
  42. not obvious whether these are safe, we can't do them at all without a
  43. mechanism to permit them.
  44. - There are many ideas circulating for alternative circuit building and
  45. cell relay rules: they don't work unless they can coexist in the
  46. current network.
  47. - If our protocol changes a lot, it's hard to describe any coherent
  48. version of it: we need to say "the version that Tor versions W through
  49. X use when talking to versions Y through Z". This makes analysis
  50. harder.
  51. Motivation: Preventing MITM attacks
  52. TLS prevents a man-in-the-middle attacker from reading or changing the
  53. contents of a communication. It does not, however, prevent such an
  54. attacker from observing timing information. Since timing attacks are some
  55. of the most effective against low-latency anonymity nets like Tor, we
  56. should take more care to make sure that we're not only talking to who
  57. we think we're talking to, but that we're using the network path we
  58. believe we're using.
  59. Motivation: Signed clock information
  60. It's very useful for Tor instances to know how skewed they are relative
  61. to one another. The only way to find out currently has been to download
  62. directory information, and check the Date header--but this is not
  63. authenticated, and hence subject to modification on the wire. Using
  64. BEGIN_DIR to create an authenticated directory stream through an existing
  65. circuit is better, but that's an extra step and it might be nicer to
  66. learn the information in the course of the regular protocol.
  67. Proposal:
  68. 1.0. Version numbers
  69. The node-to-node TLS-based "OR connection" protocol and the multi-hop
  70. "circuit" protocol are versioned quasi-independently.
  71. Of course, some dependencies will continue to exist: Certain versions
  72. of the circuit protocol may require a minimum version of the connection
  73. protocol to be used. The connection protocol affects:
  74. - Initial connection setup, link encryption, transport guarantees,
  75. etc.
  76. - The allowable set of cell commands
  77. - Allowable formats for cells.
  78. The circuit protocol determines:
  79. - How circuits are established and maintained
  80. - How cells are decrypted and relayed
  81. - How streams are established and maintained.
  82. Version numbers are incremented for backward-incompatible protocol changes
  83. only. Backward-compatible changes are generally implemented by adding
  84. additional fields to existing structures; implementations MUST ignore
  85. fields they do not expect. Unused portions of cells MUST be set to zero.
  86. Though versioning the protocol will make it easier to maintain backward
  87. compatibility with older versions of Tor, we will nevertheless continue to
  88. periodically drop support for older protocols,
  89. - to keep the implementation from growing without bound,
  90. - to limit the maintenance burden of patching bugs in obsolete Tors,
  91. - to limit the testing burden of verifying that many old protocol
  92. versions continue to be implemented properly, and
  93. - to limit the exposure of the network to protocol versions that are
  94. expensive to support.
  95. The Tor protocol as implemented through the 0.1.2.x Tor series will be
  96. called "version 1" in its link protocol and "version 1" in its relay
  97. protocol. Versions of the Tor protocol so old as to be incompatible with
  98. Tor 0.1.2.x can be considered to be version 0 of each, and are not
  99. supported.
  100. 2.1. VERSIONS cells
  101. When a Tor connection is established, both parties normally send a
  102. VERSIONS cell before sending any other cells. (But see below.)
  103. VersionsLen [2 byte]
  104. Versions [VersionsLen bytes]
  105. "Versions" is a sequence of VersionsLen bytes. Each value between 1 and
  106. 127 inclusive represents a single version; current implementations MUST
  107. ignore other bytes. Parties should list all of the versions which they
  108. are able and willing to support. Parties can only communicate if they
  109. have some connection protocol version in common.
  110. Version 0.2.0.x-alpha and earlier don't understand VERSIONS cells,
  111. and therefore don't support version negotiation. Thus, waiting until
  112. the other side has sent a VERSIONS cell won't work for these servers:
  113. if the other side sends no cells back, it is impossible to tell
  114. whether they
  115. have sent a VERSIONS cell that has been stalled, or whether they have
  116. dropped our own VERSIONS cell as unrecognized. Therefore, we'll
  117. change the TLS negotiation parameters so that old parties can still
  118. negotiate, but new parties can recognize each other. Immediately
  119. after a TLS connection has been established, the parties check
  120. whether the other side negotiated the connection in an "old" way or a
  121. "new" way. If either party negotiated in the "old" way, we assume a
  122. v1 connection. Otherwise, both parties send VERSIONS cells listing
  123. all their supported versions. Upon receiving the other party's
  124. VERSIONS cell, the implementation begins using the highest-valued
  125. version common to both cells. If the first cell from the other party
  126. has a recognized command, and is _not_ a VERSIONS cell, we assume a
  127. v1 protocol.
  128. (For more detail on the TLS protocol change, see forthcoming draft
  129. proposals from Steven Murdoch.)
  130. Implementations MUST discard VERSIONS cells that are not the first
  131. recognized cells sent on a connection.
  132. The VERSIONS cell must be sent as a v1 cell (2 bytes of circuitID, 1
  133. byte of command, 509 bytes of payload).
  134. [NOTE: The VERSIONS cell is assigned the command number 7.]
  135. 2.2. MITM-prevention and time checking
  136. If we negotiate a v2 connection or higher, the second cell we send SHOULD
  137. be a NETINFO cell. Implementations SHOULD NOT send NETINFO cells at other
  138. times.
  139. A NETINFO cell contains:
  140. Timestamp [4 bytes]
  141. Other OR's address [variable]
  142. Number of addresses [1 byte]
  143. This OR's addresses [variable]
  144. Timestamp is the OR's current Unix time, in seconds since the epoch. If
  145. an implementation receives time values from many ORs that
  146. indicate that its clock is skewed, it SHOULD try to warn the
  147. administrator. (We leave the definition of 'many' intentionally vague
  148. for now.)
  149. Before believing the timestamp in a NETINFO cell, implementations
  150. SHOULD compare the time at which they received the cell to the time
  151. when they sent their VERSIONS cell. If the difference is very large,
  152. it is likely that the cell was delayed long enough that its
  153. contents are out of date.
  154. Each address contains Type/Length/Value as used in Section 6.4 of
  155. tor-spec.txt. The first address is the one that the party sending
  156. the NETINFO cell believes the other has -- it can be used to learn
  157. what your IP address is if you have no other hints.
  158. The rest of the addresses are the advertised addresses of the party
  159. sending the NETINFO cell -- we include them
  160. to block a man-in-the-middle attack on TLS that lets an attacker bounce
  161. traffic through his own computers to enable timing and packet-counting
  162. attacks.
  163. A Tor instance should use the other Tor's reported address
  164. information as part of logic to decide whether to treat a given
  165. connection as suitable for extending circuits to a given address/ID
  166. combination. When we get an extend request, we use an
  167. existing OR connection if the ID matches, and ANY of the following
  168. conditions hold:
  169. - The IP matches the requested IP.
  170. - We know that the IP we're using is canonical because it was
  171. listed in the NETINFO cell.
  172. - We know that the IP we're using is canonical because it was
  173. listed in the server descriptor.
  174. [NOTE: The NETINFO cell is assigned the command number 8.]
  175. Discussion: Versions versus feature lists
  176. Many protocols negotiate lists of available features instead of (or in
  177. addition to) protocol versions. While it's possible that some amount of
  178. feature negotiation could be supported in a later Tor, we should prefer to
  179. use protocol versions whenever possible, for reasons discussed in
  180. the "Anonymity Loves Company" paper.
  181. Discussion: Bytes per version, versions per cell
  182. This document provides for a one-byte count of how many versions a Tor
  183. supports, and allows one byte per version. Thus, it can only support only
  184. 254 more versions of the protocol beyond the unallocated v0 and the
  185. current v1. If we ever need to split the protocol into 255 incompatible
  186. versions, we've probably screwed up badly somewhere.
  187. Nevertheless, here are two ways we could support more versions:
  188. - Change the version count to a two-byte field that counts the number of
  189. _bytes_ used, and use a UTF8-style encoding: versions 0 through 127
  190. take one byte to encode, versions 128 through 2047 take two bytes to
  191. encode, and so on. We wouldn't need to parse any version higher than
  192. 127 right now, since all bytes used to encode higher versions would
  193. have their high bit set.
  194. We'd still have a limit of 380 simultaneously versions that could be
  195. declared in any version. This is probably okay.
  196. - Decide that if we need to support more versions, we can add a
  197. MOREVERSIONS cell that gets sent before the VERSIONS cell. The spec
  198. above requires Tors to ignore unrecognized cell types that they get
  199. before the first VERSIONS cell, and still allows version negotiation
  200. to
  201. succeed.
  202. [Resolution: Reserve the high bit and the v0 value for later use. If
  203. we ever have more live versions than we can fit in a cell, we've made a
  204. bad design decision somewhere along the line.]
  205. Discussion: Reducing round-trips
  206. It might be appealing to see if we can cram more information in the
  207. initial VERSIONS cell. For example, the contents of NETINFO will pretty
  208. soon be sent by everybody before any more information is exchanged, but
  209. decoupling them from the version exchange increases round-trips.
  210. Instead, we could speculatively include handshaking information at
  211. the end of a VERSIONS cell, wrapped in a marker to indicate, "if we wind
  212. up speaking VERSION 2, here's the NETINFO I'll send. Otherwise, ignore
  213. this." This could be extended to opportunistically reduce round trips
  214. when possible for future versions when we guess the versions right.
  215. Of course, we'd need to be careful about using a feature like this:
  216. - We don't want to include things that are expensive to compute,
  217. like PK signatures or proof-of-work.
  218. - We don't want to speculate as a mobile client: it may leak our
  219. experience with the server in question.
  220. Discussion: Advertising versions in routerdescs and networkstatuses.
  221. In network-statuses:
  222. The networkstatus "v" line now has the format:
  223. "v" IMPLEMENTATION IMPL-VERSION "Link" LINK-VERSION-LIST
  224. "Circuit" CIRCUIT-VERSION-LIST NL
  225. LINK-VERSION-LIST and CIRCUIT-VERSION-LIST are comma-separated lists of
  226. supported version numbers. IMPLEMENTATION is the name of the
  227. implementation of the Tor protocol (e.g., "Tor"), and IMPL-VERSION is the
  228. version of the implementation.
  229. Examples:
  230. v Tor 0.2.5.1-alpha Link 1,2,3 Circuit 2,5
  231. v OtherOR 2000+ Link 3 Circuit 5
  232. Implementations that release independently of the Tor codebase SHOULD NOT
  233. use "Tor" as the value of their IMPLEMENTATION.
  234. Additional fields on the "v" line MUST be ignored.
  235. In router descriptors:
  236. The router descriptor should contain a line of the form,
  237. "protocols" "Link" LINK-VERSION-LIST "Circuit" CIRCUIT_VERSION_LIST
  238. Additional fields on the "protocols" line MUST be ignored.
  239. [Versions of Tor before 0.1.2.5-alpha rejected router descriptors with
  240. unrecognized items; the protocols line should be preceded with an "opt"
  241. until these Tors are obsolete.]
  242. Security issues:
  243. Client partitioning is the big danger when we introduce new versions; if a
  244. client supports some very unusual set of protocol versions, it will stand
  245. out from others no matter where it goes. If a server supports an unusual
  246. version, it will get a disproportionate amount of traffic from clients who
  247. prefer that version. We can mitigate this somewhat as follows:
  248. - Do not have clients prefer any protocol version by default until that
  249. version is widespread. (First introduce the new version to servers,
  250. and have clients admit to using it only when configured to do so for
  251. testing. Then, once many servers are running the new protocol
  252. version, enable its use by default.)
  253. - Do not multiply protocol versions needlessly.
  254. - Encourage protocol implementors to implement the same protocol version
  255. sets as some popular version of Tor.
  256. - Disrecommend very old/unpopular versions of Tor via the directory
  257. authorities' RecommmendedVersions mechanism, even if it is still
  258. technically possible to use them.