Applications should start using optimistic data
If we've got any applications that speak a protocol where latency matters, and where connections typically start out with the client sending data, then we should look into making them support optimistic data. (This means that the client sends data before hearing about whether the socks connection is successful.)
I'm calling this "bundles", but it should mostly focus on application-specific subtickets.
Activity
Shouldn't 3711 be listed as a child?
Trac:
Cc: N/A to iang@cs.uwaterloo.ca
Added #3875 (moved) as another child
While staring at my circuit window fretting about #5456 (moved), I realized that the Tor client behavior of retrying stream stages prior to RELAY_CONNECTED allows an active exit node attacker to embed an arbitrarily long timing signature transparently during stream setup. Because this phase is still transparent to the user, the circuit still can be closed at this step if the timing signature is not detected on a colluding malicious guard, allowing for resource amplification. It's not as much amplification as tagging via cipher malleability, because you don't get to do it at both ends, but it's still amplification.
But if we deploy optimistic data, we remove the amplification property because if the stream does not succeed in that first round trip, the app will actually experience failure instead of the Tor client transparently retrying until a signature can be added.
So it turns out this performance feature is actually a security improvement as well.
Trac:
Cc: iang@cs.uwaterloo.ca to iang@cs.uwaterloo.ca, rransom, arma
Parent: N/A to #5456 (moved)
Priority: normal to major-
Blech. Unfortunately, the most likely way we'll end up supporting DNSSEC will allow this timing signature to be re-introduced if the user wants end to end authentication for DNS resolutions..
We'll need to make sure there are no ways the DNS server can tell the client "try again soon, please".. I guess I should be noting this on any tickets/proposals about DNSSEC, but those have not materialized yet.
Trac:
Username: t55wang
Cc: iang@cs.uwaterloo.ca, rransom, arma to iang@cs.uwaterloo.ca, rransom, arma, t55wang@uwaterloo.ca
Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.
Trac:
Milestone: Sponsor Z: November 1, 2013 to N/A
Keywords: N/A deleted, SponsorZ addedTrac:
Cc: iang@cs.uwaterloo.ca, rransom, arma, t55wang@uwaterloo.ca to iang@cs.uwaterloo.ca, rransom, arma, t55wang@uwaterloo.ca, ln5
Karen's requested an eli5 explanation here.
So, we already went and implemented a feature in Tor that allows applications to begin sending data before they get a confirmation from the exit node that the connection has completed.
That's useful, because for protocols where the client talks first, it lets the clients avoid a "round trip" in the connection setup time. Previously, there would be 2 round trips across the network for a basic HTTP request: one to connect and wait for the exit to say "connected", and then another to send the HTTP request and wait for an HTTP response. But with this features, the connect and the HTTP request leave the client for the exit at the same time, and the "connected" and the HTTP respons can come back at the same time.
But there's a problem: Applications don't actually support this yet. Even though the application is allowed to start sending the HTTP request immediately, most of them still wait for Tor to say "you're connected!" So this performance enhancement isn't getting used.
If we come up with a workable solution here, it would let us improve applications (like say firefox) so that they start each connection faster, with less latency than they currently have.
Ah, I just realized what "eli5" meant. :-p How's this?
As we know, Tor is somewhat slow. This slowness is made worse by the following problem:
The way Tor works now, when your Tor browser wants to connect to a website (say BBC), it sends a message over the Tor network to an exit node, telling it to connect to the BBC (this is slow because sending messages over the Tor network is slow). The exit node connects to the BBC web server, and reports back to the Tor browser (over the Tor network) that it has succeeded. (This is slow because sending messages over the Tor network is slow). The Tor browser then sends a message to the BBC web server (over the Tor network) asking for a particular web page. (This is slow because sending messages over the Tor network is slow).
The key idea behind this improvement is to bundle the "which web page to get" message along with the "connect to the BBC web server" message. So with this improvement, it would look like:
When your Tor browser wants to connect to a website (say BBC), it sends a message over the Tor network to an exit node, telling it to connect to the BBC and fetch a particular web page (this is slow because sending messages over the Tor network is slow). The exit node connects to the BBC web server, and when it succeeds, the exit node then sends a message to the BBC web server (not over the Tor network) asking for the particular web page. This saves a round trip over the Tor network, and should make the Tor network much more responsive for web browsing.
-
Replying to iang:
[I still haven't parsed what "ln5" stands for, though. :-p ]
"ln5" is Linus Nordberg.
-
I think you can jettison #3711 (moved) from the children and close it yes.
In fact, done.
Trac:
Status: new to closed
Resolution: N/A to implemented mentioned in issue #6120 (moved)