Hi!
Here's a summary of the proposals that have changed their status and become closed, dead, or superseded since the last one of these emails I sent out (last year).
I'll summarize the current status of open proposals in my next mail.
I'll try to send these out more regularly.
===== Newly DEAD or SUPERSEDED:
146 Add new flag to reflect long-term stability [SUPERSEDED]
From time to time we get the idea of having clients ship with a reasonably recent consensus (or a list of directory mirrors), so instead of bootstrapping from one of the authorities, they can bootstrap from a regular directory cache. The problem here is that by the time the client is run, most of the directory mirrors will be down or will have changed their IP. This proposal tried to address that.
The applications of this design are achieved by proposal 206 instead. Instead of having the authorities track long-term stability for nodes that might be useful as directories in a fallback consensus, we eliminated the idea of a fallback consensus, and just have a DirSource configuration option.
213 Remove stream-level sendmes from the design [DEAD]
Roger had an idea to improve flow control, then decided it wasn't a good one. See the comments in this proposal for more discussion.
===== Implemented in 0.2.3 or earlier
162 Publish the consensus in multiple flavors [FINISHED]
This one got mostly implemented in 0.2.2, with the introduction of microdescriptor consensus, and in 0.2.3, where microdescriptors were finished. We never implemented the meta-document that was going to describe other, future flavors, however. I should extract that into a new proposal.
===== Implemented in 0.2.4
117 IPv6 exits [CLOSED] 208 IPv6 Exits Redux [CLOSED]
We implemented IPv6 exit support in 0.2.4.x. There are some lingering issues not addressed in these proposals -- see tickets tagged with "ipv6".
186 Multiple addresses for one OR or bridge [CLOSED]
The protocol side of this is implemented as part of the IPv6 work in 0.2.4. Tor doesn't yet use the full range of options that the format allows, however. See for example #9729 for work in that area (which needs review!)
198 Restore semantics of TLS ClientHello [CLOSED]
We did this one in 0.2.4.x. This put us back on the track of being TLS users in good standing, and let us use better ciphersuites (like ECDHE ones) than the ones we had picked out in v1 and v2 of the link protocol.
200 Adding new, extensible CREATE, EXTEND, and related cells [CLOSED] 216 Improved circuit-creation key exchange [CLOSED]
These came in 0.2.4.x; the first one allowed us to change our circuit handshake; the latter specified the ntor handshake that 0.2.4.x clients and later prefer today.
204 Subdomain support for Hidden Service addresses [FINISHED]
This one allows an (ignored) foo at the front of foo.bar.onion, for subdomain support. Sadly, I bet it will never see much use with the introduction of longer onion addresses in our next-gen hidden service design.
205 Remove global client-side DNS caching [CLOSED]
Caching DNS addresses across circuits presented a user tagging opportunity, and exposed some linkability across circuits. This proposal removed the client-side DNS cache entirely for most purposes in 0.2.4.
206 Preconfigured directory sources for bootstrapping [CLOSED]
This proposal introduces the DirSource option, with 0.2.4 clients (and later) can be set up with to avoid hammering on the authorities during their initial bootstrapping on the network.
207 Directory guards [CLOSED]
To avoid client enumeration, this proposal says that clients should use a guard . Implemented in 0.2.4.
214 Allow 4-byte circuit IDs in a new link protocol [CLOSED]
We've been at risk of having more than 65535 circuits on a link for a while now; this proposal increased the size of circuit IDs to avoid that.
221 Stop using CREATE_FAST [CLOSED]
The CREATE_FAST handshake was introduced to avoid using the TAP handshake on the first hop of circuits, since the TAP circuit extension handshake provides no benefit over the . But now that the ntor handshake is (sometimes) available, that reasoning no longer holds. Implemented in 0.2.4.
222 Stop sending client timestamps [CLOSED]
This proposal enumerated all the places in our protocol where eavesdroppers, clients, or servers get a view of a client or server's current time, and explained how to ameliorate or remove those linkability. Implemented in 0.2.4.
===== Implemented in 0.2.5
217 Tor Extended ORPort Authentication [FINISHED]
We could use an authentication step for using the extended ORPort, to ensure that local connections are coming from an authorized pluggable transport. This proposal explains how. We implemented this in 0.2.5.x as part of the ExtORPort work.
218 Controller events to better understand connection/circuit usage [CLOSED]
This one is actually going to be in 0.2.5.2-alpha; it adds more controller events for researchers.
Nick Mathewson:
204 Subdomain support for Hidden Service addresses [FINISHED]
This one allows an (ignored) foo at the front of foo.bar.onion, for subdomain support. Sadly, I bet it will never see much use with the introduction of longer onion addresses in our next-gen hidden service design.
Could you elaborate on that last statement?
AFAIK, this feature has not been advertised at all yet because 0.2.4 is still unfortunately not stable.
The initial idea was to be able to support access through a single hidden service to mass-hosting platforms, think of all blogs at *.wordpress.com or *.noblogs.org. Why would the longer onion addresses be a problem in that regard?
On Fri, Nov 15, 2013 at 7:42 AM, Lunar lunar@torproject.org wrote:
Nick Mathewson:
204 Subdomain support for Hidden Service addresses [FINISHED]
This one allows an (ignored) foo at the front of foo.bar.onion, for subdomain support. Sadly, I bet it will never see much use with the introduction of longer onion addresses in our next-gen hidden service design.
Could you elaborate on that last statement?
AFAIK, this feature has not been advertised at all yet because 0.2.4 is still unfortunately not stable.
Well, it's not *officially* stable, but it's sure the Tor I would recommend to all my friends nowadays.
The initial idea was to be able to support access through a single hidden service to mass-hosting platforms, think of all blogs at *.wordpress.com or *.noblogs.org. Why would the longer onion addresses be a problem in that regard?
So, suppose that I have a blogging platform running as a hidden service. The base hostname might be something like "cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion".
Individual blogs might be at: technology.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion, lemurs.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion, drama.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion
My thought had been that the long addresses are likely to make people a bit disinclined to use even longer addresses. But I guess we'll see; there's no reason to actually remove the feature.
On Fri, Nov 15, 2013 at 9:31 AM, Nick Mathewson nickm@torproject.org wrote:
Individual blogs might be at: technology.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion, lemurs.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion, drama.cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion
My thought had been that the long addresses are likely to make people a bit disinclined to use even longer addresses. But I guess we'll see; there's no reason to actually remove the feature.
I don't think this is a reason to remove the feature altogether, but there is a good reason not to deploy a website with user-controllable subdomains as suggested: the browser has no way of knowing that .cmktn5wni9uinp1niixoh8gzf2oqkcwckcexwe8zutfn5uu7zbb.onion is a "public suffix" and will therefore allow lemurs.yada.onion to declare that its "origin" is the entire yada.onion domain and snoop on other sites hosted there.
zw
On 14 November 2013 10:35, Nick Mathewson nickm@freehaven.net wrote:
Here's a summary of the proposals that have changed their status and become closed, dead, or superseded since the last one of these emails I sent out (last year).
<snip>
I'll try to send these out more regularly.
Nick, you're awesome. Is compiling and sending these a task which has to be done by a knowledgeable human, or is there a conceivable path to replacing yourself with a robot for this task? -Tom
On Fri, Nov 15, 2013 at 3:17 PM, Tom Lowenthal me@tomlowenthal.com wrote:
On 14 November 2013 10:35, Nick Mathewson nickm@freehaven.net wrote:
Here's a summary of the proposals that have changed their status and become closed, dead, or superseded since the last one of these emails I sent out (last year).
<snip> > I'll try to send these out more regularly.
Nick, you're awesome. Is compiling and sending these a task which has to be done by a knowledgeable human, or is there a conceivable path to replacing yourself with a robot for this task?
Let me try a few more times to set a precedent, and I'll have a better feel for it.
yrs,