[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Proposal: Optimistic Data for Tor: Server Side
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: Proposal: Optimistic Data for Tor: Server Side
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Tue, 3 Aug 2010 14:27:35 -0400
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Tue, 03 Aug 2010 14:27:43 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=TXpwWhxBkUBbLoZ0i+JXc2YYCRmubZdIXWgofPfuxPM=; b=c5tIUEbtbf4xGjMc0OYReNrv8ujYAftVYG575tkhHMPE0SYoI42Unkffr1Az+EF0p2 geniR1ZFjeTyJwFti2YGBs/1hSsJFHlSbFXxzKv/3M5iZEBvdKPcVJK5bwl4bDplf2kp MZi+mFy8UNxNaSpQy+HrbahEVRXkdaN4N7sN0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=ONIs0QwiYAyc/uApj7Btc/QdQNjLRkFvZVq/nK3E9w/bNyZYBv7c+2TmR7LKT8oWMd nbA2eudx4XmiTOii8Fuwa6RL+d/FfkUw/RBxIrbMtlj4p5ynomhwAr7vkS8qhGye+miv 5MhYaq2C/qFc1uK/hPYQCZyQxvmTEs0JY0I/g=
- In-reply-to: <20100802143101.GH30970@xxxxxxxxxxxxxxxxxxxxx>
- References: <20100802143101.GH30970@xxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
On Mon, Aug 2, 2010 at 10:31 AM, Ian Goldberg <iang@xxxxxxxxxxxxxxx> wrote:
> (My first Tor proposal; hopefully it's in a sensible form...)
>
> Here's the server side of the proposal I promised in my rump session
> talk at PETS. The server side seems harmless, and getting it deployed
> to a bunch of nodes before the client side gets out there seems like a
> good idea in any event.
>
> The client side yields both the performance improvements, as well as
> potential client fingerprinting issues. That side will have to be
> carefully considered.
>
> Discuss. ;-)
Thanks, Ian! I've added it as proposal 174.
The proposal looks good to me. I'll try to answer some of the points
that it was confused on:
> What do version numbers for hypothetical future protocol-compatible implementations look like, though?
They look like Tor version numbers, for whatever Tor version merges
the patch that implements this, and later.
> It is not clear exactly what an "unrecognized" stream is
An "unrecognized" stream is one for which we haven't yet received a
BEGIN cell. We'll also need to modify the spec to say that older
versions of Tor didn't handle RELAY_DATA cells the same way that newer
ones did.
We should consider the patch independently from the proposal. The
proposal itself looks fine. Generally, we try discussing patches on
the tracker at trac.torproject.org. We're in a loose feature-freeze
right now in a hurried attempt to release an 0.2.2.x rc, but a later
version of the patch in this proposal has a good shot IMO for 0.2.3.x.
Do you want to make the tracker entry for the patch, or should I? :)
yrs,
--
Nick Mathewson