[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r13222: Make idea proposal into proposal 130; answer question by sjm (in tor/trunk: . doc/spec/proposals doc/spec/proposals/ideas)
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@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.
-