[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] proposal 309: Optimistic SOCKS Data
commit 581b45d6527484cb29fb3471a897b5bdbd2d3eeb
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits