[or-cvs] r13222: Make idea proposal into proposal 130; answer question by sjm (in tor/trunk: . doc/spec/proposals doc/spec/proposals/ideas)

nickm at seul.org nickm at seul.org
Tue Jan 22 05:15:05 UTC 2008


Author: nickm
Date: 2008-01-22 00:15:05 -0500 (Tue, 22 Jan 2008)
New Revision: 13222

Added:
   tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt
Removed:
   tor/trunk/doc/spec/proposals/ideas/xxx-v2-conn-protocol.txt
Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/000-index.txt
   tor/trunk/doc/spec/proposals/124-tls-certificates.txt
Log:
 r17723 at catbus:  nickm | 2008-01-22 00:14:57 -0500
 Make idea proposal into proposal 130; answer question by sjmurdoch; mark 124 superseded; reindex



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r17723] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt	2008-01-21 23:29:04 UTC (rev 13221)
+++ tor/trunk/doc/spec/proposals/000-index.txt	2008-01-22 05:15:05 UTC (rev 13222)
@@ -46,11 +46,13 @@
 121  Hidden Service Authentication [OPEN]
 122  Network status entries need a new Unnamed flag [CLOSED]
 123  Naming authorities automatically create bindings [OPEN]
-124  Blocking resistant TLS certificate usage [ACCEPTED]
+124  Blocking resistant TLS certificate usage [SUPERSEDED]
 125  Behavior for bridge users, bridge relays, and bridge authorities [OPEN]
 126  Getting GeoIP data and publishing usage summaries [OPEN]
 127  Relaying dirport requests to Tor download site / website [DRAFT]
 128  Families of private bridges [DRAFT]
+129  Block Insecure Protocols by Default [OPEN]
+130  Version 2 Tor connection protocol [OPEN]
 
 
 Proposals by status:
@@ -66,9 +68,10 @@
    123  Naming authorities automatically create bindings
    125  Behavior for bridge users, bridge relays, and bridge authorities
    126  Getting GeoIP data and publishing usage summaries
+   129  Block Insecure Protocols by Default
+   130  Version 2 Tor connection protocol
  ACCEPTED:
    105  Version negotiation for the Tor protocol
-   124  Blocking resistant TLS certificate usage
  NEEDS-RESEARCH:
    118  Advertising multiple ORPorts at once
  META:
@@ -92,6 +95,7 @@
    122  Network status entries need a new Unnamed flag
  SUPERSEDED:
    112  Bring Back Pathlen Coin Weight
+   124  Blocking resistant TLS certificate usage
  DEAD:
    100  Tor Unreliable Datagram Extension Proposal
  DRAFT:

Modified: tor/trunk/doc/spec/proposals/124-tls-certificates.txt
===================================================================
--- tor/trunk/doc/spec/proposals/124-tls-certificates.txt	2008-01-21 23:29:04 UTC (rev 13221)
+++ tor/trunk/doc/spec/proposals/124-tls-certificates.txt	2008-01-22 05:15:05 UTC (rev 13222)
@@ -4,7 +4,7 @@
 Last-Modified: $Date$
 Author: Steven J. Murdoch
 Created: 2007-10-25
-Status: Accepted
+Status: Superseded
 
 Overview:
 

Copied: tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt (from rev 13154, tor/trunk/doc/spec/proposals/ideas/xxx-v2-conn-protocol.txt)
===================================================================
--- tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt	                        (rev 0)
+++ tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt	2008-01-22 05:15:05 UTC (rev 13222)
@@ -0,0 +1,185 @@
+Filename: 130-v2-conn-protocol.txt
+Title: Version 2 Tor connection protocol
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 2007-10-25
+Status: Open
+
+Overview:
+
+  This proposal describes the significant changes to be made in the v2
+  Tor connection protocol.
+
+  This proposal relates to other proposals as follows:
+
+    It refers to and supersedes:
+       Proposal 124: Blocking resistant TLS certificate usage
+    It refers to aspects of:
+       Proposal 105: Version negotiation for the Tor protocol
+       Proposal 110: Avoid infinite length circuits
+
+
+  In summary, The Tor connection protocol has been in need of a redesign
+  for a while.  This proposal describes how we can add to the Tor
+  protocol:
+
+     - A new TLS handshake (to achieve blocking resistance without
+       breaking backward compatibility)
+     - Version negotiation (so that future connection protocol changes
+       can happen without breaking compatibility)
+     - The actual changes in the v2 Tor connection protocol.
+
+Motivation:
+
+  For motivation, see proposal 124.
+
+Proposal:
+
+0. Terminology
+
+  The version of the Tor connection protocol implemented up to now is
+  "version 1".  This proposal describes "version 2".
+
+  "Old" or "Older" versions of Tor are ones not aware that version 2
+  of this protocol exists;
+  "New" or "Newer" versions are ones that are.
+
+  The connection initiator is referred to below as the Client; the
+  connection responder is referred to below as the Server.
+
+1. The revised TLS handshake.
+
+  For motivation, see proposal 124.  This is a simplified version of the
+  handshake that uses TLS's renegotiation capability in order to avoid
+  some of the extraneous steps in proposal 124.
+
+  The Client connects to the Server and, as in ordinary TLS, sends a
+  list of ciphers.  Older versions of Tor will send only ciphers from
+  the list:
+    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
+    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
+    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
+    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+  Clients that support the revised handshake will send the recommended
+  list of ciphers from proposal 124, in order to emulate the behavior of
+  a web browser.
+
+  If the server notices that the list of ciphers contains only ciphers
+  from this list, it proceeds with Tor's version 1 TLS handshake as
+  documented in tor-spec.txt.
+
+  (The server may also notice cipher lists used by other implementations
+  of the Tor protocol (in particular, the BouncyCastle default cipher
+  list as used by some Java-based implementations), and whitelist them.)
+
+  On the other hand, if the server sees a list of ciphers that could not
+  have been sent from an older implementation (because it includes other
+  ciphers, and does not match any known-old list), the server sends a
+  reply containing a single connection certificate, constructed as for
+  the link certificate in the v1 Tor protocol.  The subject names in
+  this certificate SHOULD NOT have any strings to identify them as
+  coming from a Tor server.  The server does not ask the client for
+  certificates.
+
+  Old Servers will (mostly) ignore the cipher list and respond as in the v1
+  protocol, sending back a two-certificate chain.
+
+  After the Client gets a response from the server, it checks for the
+  number of certificates it received.  If there are two certificates,
+  the client assumes a V1 connection and proceeds as in tor-spec.txt.
+  But if there is only one certificate, the client assumes a V2 or later
+  protocol and continues.
+
+  At this point, the client has established a TLS connection with the
+  server, but the parties have not been authenticated: the server hasn't
+  sent its identity certificate, and the client hasn't sent any
+  certificates at all.  To fix this, the client begins a TLS session
+  renegotiation.  This time, the server continues with two certificates
+  as usual, and asks for certificates so that the client will send
+  certificates of its own.  Because the TLS connection has been
+  established, all of this is encrypted.  (The certificate sent by the
+  server in the renegotiated connection need not be the same that
+  as sentin the original connection.)
+
+  The server MUST NOT write any data until the client has renegotiated.
+
+  Once the renegotiation is finished, the server and client check one
+  another's certificates as in V1.  Now they are mutually authenticated.
+
+1.1. Revised TLS handshake: implementation notes.
+
+  It isn't so easy to adjust server behavior based on the client's
+  ciphersuite list.  Here's how we can do it using OpenSSL.  This is a
+  bit of an abuse of the OpenSSL APIs, but it's the best we can do, and
+  we won't have to do it forever.
+
+  We can use OpenSSL's SSL_set_info_callback() to register a function to
+  be called when the state changes.  The type/state tuple of
+     SSL_CB_ACCEPT_LOOP/SSL3_ST_SW_SRVR_HELLO_A
+  happens when we have completely parsed the client hello, and are about
+  to send a response.  From this callback, we can check the cipherlist
+  and act accordingly:
+
+     * If the ciphersuite list indicates a v1 protocol, we set the
+       verify mode to SSL_VERIFY_NONE with a callback (so we get
+       certificates).
+
+     * If the ciphersuite list indicates a v2 protocol, we set the
+       verify mode to SSL_VERIFY_NONE with no callback (so we get
+       no certificates) and set the SSL_MODE_NO_AUTO_CHAIN flag (so that
+       we send only 1 certificate in the response.
+
+  Once the handshake is done, the server clears the
+  SSL_MODE_NO_AUTO_CHAIN flag and sets the callback as for the V1
+  protocol.  It then starts reading.
+
+  The other problem to take care of is missing ciphers and OpenSSL's
+  cipher sorting algorithms. The two main issues are a) OpenSSL doesn't
+  support some of the default ciphers that Firefox advertises, and b)
+  OpenSSL sorts the list of ciphers it offers in a different way than
+  Firefox sorts them, so unless we fix that Tor will still look different
+  than Firefox.
+  [XXXX more on this.]
+
+
+1.2. Compatibility for clients using libraries less hackable than OpenSSL.
+
+  As discussed in proposal 105, servers advertise which protocol
+  versions they support in their router descriptors.  Clients can simply
+  behave as v1 clients when connecting to servers that do not support
+  link version 2 or higher, and as v2 clients when connecting to servers
+  that do support link version 2 or higher.
+
+  (Servers can't use this strategy because we do not assume that servers
+  know one another's capabilities when connecting.)
+
+2. Version negotiation.
+
+  Version negotiation proceeds as described in proposal 105, except as
+  follows:
+
+   * Version negotiation only happens if the TLS handshake as described
+     above completes.
+
+   * The TLS renegotiation must be finished before the client sends a
+     VERSIONS cell; the server sends its VERSIONS cell in response.
+
+   * The VERSIONS cell uses the following variable-width format:
+         Circuit  [2 octets; set to 0]
+         Command  [1 octet; set to 7 for VERSIONS]
+         Length   [2 octets; big-endian]
+         Data     [Length bytes]
+
+     The Data in the cell is a series of big-endian two-byte integers.
+
+3. The rest of the "v2" protocol
+
+   Once a v2 protocol has been negotiated, NETINFO cells are exchanged
+   as in proposal 105, and communications begin as per tor-spec.txt.
+
+   RELAY_EARLY cells are accepted as in proposal 110, and treated as
+   RELAY cells except that they are relayed as RELAY_EARLY if the next
+   host in the circuit has negotiated v2 or later; otherwise, not.
+   Command value 9 is used for RELAY_EARLY.
+

Deleted: tor/trunk/doc/spec/proposals/ideas/xxx-v2-conn-protocol.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-v2-conn-protocol.txt	2008-01-21 23:29:04 UTC (rev 13221)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-v2-conn-protocol.txt	2008-01-22 05:15:05 UTC (rev 13222)
@@ -1,183 +0,0 @@
-Filename: xxx-v2-conn-protocol.txt
-Title: Version 2 Tor connection protocol
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 2007-10-25
-Status: Draft
-
-Overview:
-
-  This proposal describes the significant changes to be made in the v2
-  Tor connection protocol.
-
-  This proposal relates to other proposals as follows:
-
-    It refers to and supersedes:
-       Proposal 124: Blocking resistant TLS certificate usage
-    It refers to aspects of:
-       Proposal 105: Version negotiation for the Tor protocol
-       Proposal 110: Avoid infinite length circuits
-
-
-  In summary, The Tor connection protocol has been in need of a redesign
-  for a while.  This proposal describes how we can add to the Tor
-  protocol:
-
-     - A new TLS handshake (to achieve blocking resistance without
-       breaking backward compatibility)
-     - Version negotiation (so that future connection protocol changes
-       can happen without breaking compatibility)
-     - The actual changes in the v2 Tor connection protocol.
-
-Motivation:
-
-  For motivation, see proposal 124.
-
-Proposal:
-
-0. Terminology
-
-  The version of the Tor connection protocol implemented up to now is
-  "version 1".  This proposal describes "version 2".
-
-  "Old" or "Older" versions of Tor are ones not aware that version 2
-  of this protocol exists;
-  "New" or "Newer" versions are ones that are.
-
-  The connection initiator is referred to below as the Client; the
-  connection responder is referred to below as the Server.
-
-1. The revised TLS handshake.
-
-  For motivation, see proposal 124.  This is a simplified version of the
-  handshake that uses TLS's renegotiation capability in order to avoid
-  some of the extraneous steps in proposal 124.
-
-  The Client connects to the Server and, as in ordinary TLS, sends a
-  list of ciphers.  Older versions of Tor will send only ciphers from
-  the list:
-    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-  Clients that support the revised handshake will send the recommended
-  list of ciphers from proposal 124, in order to emulate the behavior of
-  a web browser.
-
-  If the server notices that the list of ciphers contains only ciphers
-  from this list, it proceeds with Tor's version 1 TLS handshake as
-  documented in tor-spec.txt.
-
-  (The server may also notice cipher lists used by other implementations
-  of the Tor protocol (in particular, the BouncyCastle default cipher
-  list as used by some Java-based implementations), and whitelist them.)
-
-  On the other hand, if the server sees a list of ciphers that could not
-  have been sent from an older implementation (because it includes other
-  ciphers, and does not match any known-old list), the server sends a
-  reply containing a single connection certificate, constructed as for
-  the link certificate in the v1 Tor protocol.  The subject names in
-  this certificate SHOULD NOT have any strings to identify them as
-  coming from a Tor server.  The server does not ask the client for
-  certificates.
-
-  Old Servers will (mostly) ignore the cipher list and respond as in the v1
-  protocol, sending back a two-certificate chain.
-
-  After the Client gets a response from the server, it checks for the
-  number of certificates it received.  If there are two certificates,
-  the client assumes a V1 connection and proceeds as in tor-spec.txt.
-  But if there is only one certificate, the client assumes a V2 or later
-  protocol and continues.
-
-  At this point, the client has established a TLS connection with the
-  server, but the parties have not been authenticated: the server hasn't
-  sent its identity certificate, and the client hasn't sent any
-  certificates at all.  To fix this, the client begins a TLS session
-  renegotiation.  This time, the server continues with two certificates
-  as usual, and asks for certificates so that the client will send
-  certificates of its own.  Because the TLS connection has been
-  established, all of this is encrypted.
-
-  The server MUST NOT write any data until the client has renegotiated.
-
-  Once the renegotiation is finished, the server and client check one
-  another's certificates as in V1.  Now they are mutually authenticated.
-
-1.1. Revised TLS handshake: implementation notes.
-
-  It isn't so easy to adjust server behavior based on the client's
-  ciphersuite list.  Here's how we can do it using OpenSSL.  This is a
-  bit of an abuse of the OpenSSL APIs, but it's the best we can do, and
-  we won't have to do it forever.
-
-  We can use OpenSSL's SSL_set_info_callback() to register a function to
-  be called when the state changes.  The type/state tuple of
-     SSL_CB_ACCEPT_LOOP/SSL3_ST_SW_SRVR_HELLO_A
-  happens when we have completely parsed the client hello, and are about
-  to send a response.  From this callback, we can check the cipherlist
-  and act accordingly:
-
-     * If the ciphersuite list indicates a v1 protocol, we set the
-       verify mode to SSL_VERIFY_NONE with a callback (so we get
-       certificates).
-
-     * If the ciphersuite list indicates a v2 protocol, we set the
-       verify mode to SSL_VERIFY_NONE with no callback (so we get
-       no certificates) and set the SSL_MODE_NO_AUTO_CHAIN flag (so that
-       we send only 1 certificate in the response.
-
-  Once the handshake is done, the server clears the
-  SSL_MODE_NO_AUTO_CHAIN flag and sets the callback as for the V1
-  protocol.  It then starts reading.
-
-  The other problem to take care of is missing ciphers and OpenSSL's
-  cipher sorting algorithms. The two main issues are a) OpenSSL doesn't
-  support some of the default ciphers that Firefox advertises, and b)
-  OpenSSL sorts the list of ciphers it offers in a different way than
-  Firefox sorts them, so unless we fix that Tor will still look different
-  than Firefox.
-  [XXXX more on this.]
-
-
-1.2. Compatibility for clients using libraries less hackable than OpenSSL.
-
-  As discussed in proposal 105, servers advertise which protocol
-  versions they support in their router descriptors.  Clients can simply
-  behave as v1 clients when connecting to servers that do not support
-  link version 2 or higher, and as v2 clients when connecting to servers
-  that do support link version 2 or higher.
-
-  (Servers can't use this strategy because we do not assume that servers
-  know one another's capabilities when connecting.)
-
-2. Version negotiation.
-
-  Version negotiation proceeds as described in proposal 105, except as
-  follows:
-
-   * Version negotiation only happens if the TLS handshake as described
-     above completes.
-
-   * The TLS renegotiation must be finished before the client sends a
-     VERSIONS cell; the server sends its VERSIONS cell in response.
-
-   * The VERSIONS cell uses the following variable-width format:
-         Circuit  [2 octets; set to 0]
-         Command  [1 octet; set to 7 for VERSIONS]
-         Length   [2 octets; big-endian]
-         Data     [Length bytes]
-
-     The Data in the cell is a series of big-endian two-byte integers.
-
-3. The rest of the "v2" protocol
-
-   Once a v2 protocol has been negotiated, NETINFO cells are exchanged
-   as in proposal 105, and communications begin as per tor-spec.txt.
-
-   RELAY_EARLY cells are accepted as in proposal 110, and treated as
-   RELAY cells except that they are relayed as RELAY_EARLY if the next
-   host in the circuit has negotiated v2 or later; otherwise, not.
-   Command value 9 is used for RELAY_EARLY.
-



More information about the tor-commits mailing list