commit 581b45d6527484cb29fb3471a897b5bdbd2d3eeb Author: Nick Mathewson <nickm@torproject.org> Date: Wed Oct 2 13:40:35 2019 -0400 proposal 309: Optimistic SOCKS Data --- proposals/000-index.txt | 6 ++- proposals/309-optimistic-socks-in-tor.txt | 78 +++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index f65f50e..6e7b802 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -222,13 +222,14 @@ Proposals by number: 299 Preferring IPv4 or IPv6 based on IP Version Failure Count [OPEN] 300 Walking Onions: Scaling and Saving Bandwidth [DRAFT] 301 Don't include package fingerprints in consensus documents [ACCEPTED] -302 Hiding onion service clients using padding [ACCEPTED] +302 Hiding onion service clients using padding [CLOSED] 303 When and how to remove support for protocol versions [DRAFT] 304 Extending SOCKS5 Onion Service Error Codes [ACCEPTED] 305 ESTABLISH_INTRO Cell DoS Defense Extension [DRAFT] 306 A Tor Implementation of IPv6 Happy Eyeballs [OPEN] 307 Onion Balance Support for Onion Service v3 [DRAFT] 308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [DRAFT] +309 Optimistic SOCKS Data [DRAFT] Proposals by status: @@ -242,6 +243,7 @@ Proposals by status: 305 ESTABLISH_INTRO Cell DoS Defense Extension 307 Onion Balance Support for Onion Service v3 308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography + 309 Optimistic SOCKS Data NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] @@ -273,7 +275,6 @@ Proposals by status: 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) 292 Mesh-based vanguards 301 Don't include package fingerprints in consensus documents - 302 Hiding onion service clients using padding 304 Extending SOCKS5 Onion Service Error Codes META: 000 Index of Tor Proposals @@ -376,6 +377,7 @@ Proposals by status: 293 Other ways for relays to know when to publish [for 0.3.5] [in 0.4.0.1-alpha] 297 Relaxing the protover-based shutdown rules [for 0.3.5.x] [in 0.4.0.x] 298 Putting family lines in canonical form [for 0.3.6.x] [in 0.4.0.1-alpha] + 302 Hiding onion service clients using padding [in 0.4.1.1-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration diff --git a/proposals/309-optimistic-socks-in-tor.txt b/proposals/309-optimistic-socks-in-tor.txt new file mode 100644 index 0000000..dbd7af6 --- /dev/null +++ b/proposals/309-optimistic-socks-in-tor.txt @@ -0,0 +1,78 @@ +Filename: 309-optimistic-socks-in-tor.txt +Title: Optimistic SOCKS Data +Author: Tom Ritter +Created: 21-June-2019 +Status: Draft +Ticket: #5915 + +0. Abstract + + We propose that tor should have a SocksPort option that causes it to lie + to the application that the SOCKS Handshake has succeeded immediately, + allowing the application to begin sending data optimistically. + +1. Introduction + + In the past, Tor Browser had a patch that allowed it to send data + optimistically. This effectively eliminated a round trip through the + entire circuit, reducing latency. + + This feature was buggy, and specifically caused problems with MOAT, as + described in [0] and Tor Messenger as described in [1]. It is possible + that the other issues observed with it were the same issue, it is + possible they were different. + + Rather than trying to identify and fix the problem in Tor Browser, an + alternate idea is to have tor lie to the application, causing it to send + the data optimistically. This can benefit all users of tor. This + proposal documents that idea. + + [0] https://trac.torproject.org/projects/tor/ticket/24432#comment:19 + [1] https://trac.torproject.org/projects/tor/ticket/19910#comment:3 + +2. Proposal + +2.1. Behavior + + When the SocksPort flag defined below is present, Tor will immediately + report a successful SOCKS handshake subject for non-onion connections. + If, later, tor recieves an end cell rather than a connected cell, it + will hang up the SOCKS connection. + + The requirement to omit this for onion connections is because in + #30382 we implemented a mechanism to return a special SOCKS error code + if we are connecting to an onion site that requires authentication. + Returning an early success would prevent this from working. + + Redesigning the mechanism to communicate auth-required onion sites to + the browser, while also supporting optimistic data, are left to a future + proposal. + +2.2. New SocksPort Flag + + In order to have backward compatibility with third party applications that + do not support or do not want to use optimistic data, we propose a new + SocksPort flag that needs to be set in the tor configuration file in order + for the optimistic beahvior to occur. + + The new SocksPort flag is: + + "OptimisticData" -- Tor will immediately report a successful SOCKS + handshake subject for non-onion connections and + hang up if it gets an end cell rather than a + connected cell. + +3. Application Error Handling + + This behavior will cause the application talking to Tor to potentially + behave abnormally as it will believe that it has completed a TCP + connection. If no such connection can be made by tor, the program may + behave in a way that does not accurately represent the behavior of the + connection. + + Applications SHOULD test various connection failure modes and ensure their + behavior is acceptable before using this feature. + +References: + +[RFC1928] https://www.ietf.org/rfc/rfc1928.txt