[tor-commits] [torspec/master] proposal 309: Optimistic SOCKS Data

Wed Oct 2 17:40:39 UTC 2019

commit 581b45d6527484cb29fb3471a897b5bdbd2d3eeb
Author: Nick Mathewson <nickm at 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

