[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r12031: Changes to proposal 105 based on recent or-dev exchange with (in tor/trunk: . doc/spec/proposals)
Author: nickm
Date: 2007-10-18 14:35:06 -0400 (Thu, 18 Oct 2007)
New Revision: 12031
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/105-handshake-revision.txt
Log:
r15931@catbus: nickm | 2007-10-18 14:34:05 -0400
Changes to proposal 105 based on recent or-dev exchange with sjmurdoch.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r15931] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/spec/proposals/105-handshake-revision.txt
===================================================================
--- tor/trunk/doc/spec/proposals/105-handshake-revision.txt 2007-10-18 18:16:52 UTC (rev 12030)
+++ tor/trunk/doc/spec/proposals/105-handshake-revision.txt 2007-10-18 18:35:06 UTC (rev 12031)
@@ -120,11 +120,12 @@
When a Tor connection is established, both parties normally send a
VERSIONS cell before sending any other cells. (But see below.)
- NumVersions [1 byte]
+ VersionsLen [1 byte]
Versions [NumVersions bytes]
- "Versions" is a sequence of NumVersions link connection protocol versions,
- each one byte long. Parties should list all of the versions which they
+ "Versions" is a sequence of NumVersions bytes. Each value between 1 and
+ 127 inclusive represents a single version; current implementations MUST
+ ignore other bytes. Parties should list all of the versions which they
are able and willing to support. Parties can only communicate if they
have some connection protocol version in common.
@@ -133,18 +134,24 @@
the other side has sent a VERSIONS cell won't work for these servers:
if the other side sends no cells back, it is impossible to tell
whether they
+
have sent a VERSIONS cell that has been stalled, or whether they have
- dropped our own VERSIONS cell as unrecognized. Thus, immediately after
- a TLS connection has been established, the parties check whether the
- other side has an obsolete certificate (organizationName equal to "Tor"
- or "TOR"). If the other party presented an obsolete certificate,
- we assume a v1 connection. Otherwise, both parties send VERSIONS
- 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 has a recognized command, and is _not_ a VERSIONS cell, we
- assume a v1 protocol.
+ dropped our own VERSIONS cell as unrecognized. Therefore, we'll
+ change the TLS negotiation parameters so that old parties can still
+ negotiate, but new parties can recognize each other. Immediately
+ after a TLS connection has been established, the parties check
+ whether the other side negotiated the connection in an "old" way or a
+ "new" way. If either party negotiated in the "old" way, we assume a
+ v1 connection. Otherwise, both parties send VERSIONS 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
+ has a recognized command, and is _not_ a VERSIONS cell, we assume a
+ v1 protocol.
+ (For more detail on the TLS protocol change, see forthcoming draft
+ proposals from Steven Murdoch.)
+
Implementations MUST discard VERSIONS cells that are not the first
recognized cells sent on a connection.
@@ -159,8 +166,9 @@
A NETINFO cell contains:
Timestamp [4 bytes]
- This OR's address [variable]
Other OR's address [variable]
+ Number of addresses [1 byte]
+ This OR's addresses [variable]
Timestamp is the OR's current Unix time, in seconds since the epoch. If
an implementation receives time values from many ORs that
@@ -168,23 +176,32 @@
administrator. (We leave the definition of 'many' intentionally vague
for now.)
+ Before believing the timestamp in a NETINFO cell, implementations
+ SHOULD compare the time at which they received the cell to the time
+ when they sent their VERSIONS cell. If the difference is very large,
+ it is likely that the cell was delayed long enough that its
+ contents are out of date.
+
Each address contains Type/Length/Value as used in Section 6.4 of
- tor-spec.txt. The first address is the address of the interface the
- party sending the NETINFO cell
- used to connect to or accept connections from the other -- we include it
+ tor-spec.txt. The first address is the one that the party sending
+ the NETINFO cell believes the other has -- it can be used to learn
+ what your IP address is if you have no other hints.
+ The rest of the addresses are the advertised addresses of the party
+ sending the NETINFO cell -- we include them
to block a man-in-the-middle attack on TLS that lets an attacker bounce
traffic through his own computers to enable timing and packet-counting
attacks.
- The second address is the one that the party sending the NETINFO cell
- believes the other has -- it can be used to learn what your IP address
- is if you have no other hints.
+ If a party connects to an OR based on an EXTEND cell, and the address
+ given in the EXTEND cell is not listed in the NETINFO cell, the first
+ party SHOULD close the connection as a likely MITM attack.
+
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
+ feature 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.
@@ -210,9 +227,14 @@
- 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 allows version negotiation to
+ before the first VERSIONS cell, and still allows version negotiation
+ to
succeed.
+ [Resolution: Reserve the high bit and the v0 value for later use. If
+ we ever have more live versions than we can fit in a cell, we've made a
+ bad design decision somewhere along the line.]
+
Discussion: Reducing round-trips
It might be appealing to see if we can cram more information in the
@@ -266,7 +288,6 @@
unrecognized items; the protocols line should be preceded with an "opt"
until these Tors are obsolete.]
-
Security issues:
Client partitioning is the big danger when we introduce new versions; if a