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.
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
