commit 99a660b440a46ba9e25c02273acda6dfd36c7ff7
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Wed Sep 9 12:24:02 2015 -0400
Make a bunch of notes in proposal-status.txt
---
proposals/proposal-status.txt | 133 ++++++++++++++++++++++++++++++++++++++---
1 file changed, 124 insertions(+), 9 deletions(-)
diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt
index f094583..869ef1b 100644
--- a/proposals/proposal-status.txt
+++ b/proposals/proposal-status.txt
@@ -65,6 +65,8 @@ again to remind me!
Probably, there are better choices when it comes to
distributing software and updates. (11/2013)
+ I say, mark it OBSOLETE. (9/2015)
+
131 Help users to verify they are using Tor [NEEDS-REVISION]
This one is not a crazy idea, but I marked it as
@@ -72,6 +74,9 @@ again to remind me!
our current designs. It seems mostly superseded by proposal
211. (11/2013)
+ I say, mark it as OBSOLETE and make a note on proposal 211 to see it for
+ historical information. (9/2015)
+
132 A Tor Web Service For Verifying Correct Browser Configuration
This proposal was meant to give users a way to see if their
@@ -81,6 +86,8 @@ again to remind me!
that run webservers on localhost, since they become a target
for cross-site attacks. (11/2013)
+ I say mark as OBSOLETE. (9/2015)
+
133 Incorporate Unreachable ORs into the Tor Network
This proposal had an idea for letting ORs that can only make
@@ -90,13 +97,20 @@ again to remind me!
who wants to analyze new network topologies should definitely
have a look. (5/2011)
+ For this I think we should introduce a new proposal status,
+ "RESERVE". A proposal is "on reserve" if we're not currently
+ planning to implement it, but we might someday want to do so if we
+ decide that what it provides is a great idea. (9/2015)
+
140 Provide diffs between consensuses
This proposal describes a way to transmit less directory
traffic by sending only differences between consensuses, rather
than the consensuses themselves. Daniel Marti implemented this for his
GSoC project last summer; it is still under revision and on target
- for merge into 0.2.7. (See ticket #13339) (2/2015)
+ for merge into 0.2.8. (See ticket #13339) (9/2015)
+
+ This needs code review, and needs to marked as ACCCEPTED. (9/2015)
141 Download server descriptors on demand
@@ -110,6 +124,8 @@ again to remind me!
some difficulties in using in a way compatible with
it. (6/2012)
+ I say mark this as OBSOLETE or RESERVE. (9/2015)
+
143 Improvements of Distributed Storage for Tor Hidden Service
Descriptors
@@ -130,6 +146,7 @@ again to remind me!
This is probably superseded by proposal 224; we should close it
IMO. (2/2014)
+ Time to mark this as SUPERSEDED. (9/2015)
144 Increase the diversity of circuits by detecting nodes
belonging the same provider
@@ -142,6 +159,10 @@ again to remind me!
did in 2008, particularly in light of the relevant paper(s) by
Matt Edmann and Paul Syverson. (5/2011)
+ Mark as OBSOLETE. The research field has advanced very far since
+ this proposal, and new papers on this topic come out every year.
+ (9/2015)
+
145 Separate "suitable as a guard" from "suitable as a new guard"
[NEEDS-RESEARCH]
@@ -160,6 +181,8 @@ again to remind me!
approach for weighting guard node selection probabilities; we
should probably close this ticket. (2/2015)
+ I say, mark as OBSOLETE. (9/2015)
+
156 Tracking blocked ports on the client side
This proposal provides a way for clients to learn which ports
@@ -192,6 +215,8 @@ again to remind me!
This is an overview of SoaT, with some ideas for how to integrate
it into Tor. (5/2011)
+ (Mark as HISTORICAL? INFORMATIONAL?) (9/2015)
+
164 Reporting the status of server votes
This proposal explains a way for authorities to provide a
@@ -203,6 +228,8 @@ again to remind me!
implement, and would be a fine project for somebody who wants
to get to know the directory code. (5/2011)
+ Mark as RESERVE. (9/2015)
+
165 Easy migration for voting authority sets
This is a design for how to change the set of authorities without
@@ -222,6 +249,8 @@ again to remind me!
0.2.1.20? If so, we should make sure that tor-spec.txt is
updated and close it. (11/2013)
+ Should update Tor-spec, should close this. (9/2015)
+
172 GETINFO controller option for circuit information
173 GETINFO Option Expansion
@@ -230,6 +259,9 @@ again to remind me!
accepted and some parts of 173 are even implemented: somebody
just needs to implement the rest. (5/2011)
+ Should mark as ACCEPTED; should open tickets for them; should
+ consider whether they're needed, though. (9/2015)
+
175 Automatically promoting Tor clients to nodes
Here's Steven's proposal for adding a mode between "client
@@ -238,6 +270,9 @@ again to remind me!
attention when it was posted to the list; more people should
review it. (5/2011)
+ Mark as REJECTED. I don't see us doing this any time soon.
+ (9/2015)
+
177 Abstaining from votes on individual flags
Here's my proposal for letting authorities have opinions about some
@@ -246,6 +281,9 @@ again to remind me!
right. With more discussion and review, somebody could/should
build it, I think. (11/2013)
+ Mark as RESERVE. I still love this idea, but nobody else seems
+ to think it's necessary (9/2015)
+
182 Credit Bucket
This proposal suggests an alternative approach to our current
@@ -260,12 +298,19 @@ again to remind me!
explains how we can get rid of the requirement that non-bridge
directories have an open directory port. (6/2012)
+ Mark as ACCEPTED, after updating it to match in-progress work for
+ "everybody is a directory", which is ontrack for 0.2.8. Or maybe
+ that work is closer to 237? (9/2015)
+
188 Bridge Guards and other anti-enumeration defenses
This proposal suggests some ways to make it harder for a relay
on the Tor network to enumerate a list of Tor bridges. Worth
investigating and possibly implementing. (6/2012)
+ Update and then mark as ACCEPTED; isis has code for this for 0.2.8.
+ (9/2015)
+
189 AUTHORIZE and AUTHORIZED cells
190 Bridge Client Authorization Based on a Shared Secret [NEEDS-REVISION]
191 Bridge Detection Resistance against MITM-capable Adversaries
@@ -277,6 +322,8 @@ again to remind me!
Number 190 needs revision, since its protocol isn't actually
so great. (11/2013)
+ Mark as RESERVE. (9/2015)
+
192 Automatically retrieve and store information about bridges
This proposal gives an enhancement to the bridge information
@@ -284,6 +331,8 @@ again to remind me!
are able to update what they know about them over time. Could
help a lot with bridge churn. (6/2012)
+ Mark as RESERVE? Do we still even want this? (9/2015)
+
194 Mnemonic .onion URLs
Here's one of several competing "let's make .onion URLs
@@ -292,6 +341,9 @@ again to remind me!
we go ahead with current plans for hidden services that
would make .onion addresses much longer, though. (11/2013)
+ We're not going to do this like this, I think. Mark as
+ SUPERSEDED. (9/2015)
+
195 TLS certificate normalization for Tor 0.2.4.x
Here's the followup to proposal 179, containing all the parts
@@ -306,6 +358,9 @@ again to remind me!
fingerprinting can be helpful for snoops; we should take another
look at it. (2/2015)
+ I think we should take a pass over this, pick the parts we still
+ think are relevant, and call them ACCEPTED. (9/2015)
+
196 Extended ORPort and TransportControlPort
Here are some remaining pieces of the pluggable transport
@@ -314,6 +369,9 @@ again to remind me!
now; we should figure out what's left, and whether we want
to build that. (11/2013)
+ I think we should mark this FINISHED. We're not going to do more
+ than we have now, afaik. (9/2015)
+
197 Message-based Inter-Controller IPC Channel
This proposal is for an architectural enhancement in Tor
@@ -321,6 +379,9 @@ again to remind me!
various programs (Vidalia, TorBrowser, etc) that are using
it. (6/2012)
+ Mark as RESERVE or REJECTED. Nobody's asked for this in a really
+ long time, and I don't want to be dbus. (9/2015)
+
199 Integration of BridgeFinder and BridgeFinderHelper
Here's a proposal for how Tor can integrate with a client
@@ -328,6 +389,8 @@ again to remind me!
done on things called "BridgeFinder"; I don't know what the
status of the current proposal is, though. (11/2013)
+ Mark as OBSOLETE? I don't think this is still a thing. (9/2015)
+
201 Make bridges report statistics on daily v3 network status requests
Here's a proposal for bridges to better estimate the number of
@@ -336,9 +399,11 @@ again to remind me!
202 Two improved relay encryption protocols for Tor cells
Here's a sketch of the two broad classes of alternatives for
- improving how relay encryption works. Right now, progress on
- this proposal is stalled waiting for the ideal wide-block
- construction to come along the line. (11/2013)
+ improving how relay encryption works. Right now, progress on this
+ proposal is stalled waiting for the ideal wide-block construction
+ to come along the line. AEZ seems like it might be close to what
+ we need. Other cryptographers are also looking at designs that
+ might be a good match. (9/2015)
203 Avoiding censorship by impersonating an HTTPS server
@@ -346,6 +411,8 @@ again to remind me!
HTTPS server (by *being* an HTTPS server) until the user
proves they know it's a bridge. (11/2013)
+ Didn't we do something like this? (9/2015)
+
209 Tuning the Parameters for the Path Bias Defense
In this proposal, Mike discusses alternative parameters for
@@ -361,6 +428,9 @@ again to remind me!
consensus from non-Authority DirSources, but we shouldnt' do
anything to increase the load on authorities. (11/2013)
+ This needs an update; it's a pretty good idea, and Mike and Roger
+ like it. It goes will with FallbackDirSource stuff. (9/2015)
+
211 Internal Mapaddress for Tor Configuration Testing
Here, the idea is to serve an XML document over HTTP that
@@ -371,6 +441,8 @@ again to remind me!
the idea of having any more magical addresses like this; we
got rid of .noconnect for a reason, after all. (11/2013)
+ Mark as REJECTED. (9/2015)
+
212 Increase Acceptable Consensus Age
This proposal suggests that we increase the maximum age of a
@@ -381,6 +453,8 @@ again to remind me!
was some tor-dev discussion on this one that should get
incorporated into a final, implementable version. (11/2013)
+ Mark as ACCEPTED? (9/2015)
+
219 Support for full DNS and DNSSEC resolution in Tor
Here's a design to allow Tor to support a full range of DNS
@@ -394,8 +468,10 @@ again to remind me!
done with reasonable confidence, and figure out the client side
once more servers have upgraded. (12/2013)
+ Mark as NEEDS-REVISION? (9/2015)
+
220 Migrate server identity keys to Ed25519
-v
+
This one is a design to migrate server identity keys to
Ed25519 for improved security margin. It needs more analysis of
long-term migration to other signing key types -- what do we do
@@ -408,6 +484,9 @@ v
out out fairly soon. Other proposals, like 224, depend on this
one. (2/2015)
+ Mark as ACCEPTED. Some is implemented in 0.2.7; the rest is
+ in-progress. (9/2015)
+
223 Ace: Improved circuit-creation key exchange
Here's an interesting one. It proposes a replacement for the
@@ -446,12 +525,16 @@ v
something better. Some alternatives have already been discussed
on tor-dev; more work is needed, though. (12/2013)
+ Mark as SUPERSEDED by proposal 250. (9/2015)
+
226 Scalability and Stability Improvements to BridgeDB:
Switching to a Distributed Database System and RDBMS
This one outlines design and behavior changes for a seriously
refactored bridgedb. (2/2014)
+ I should find out if Isis has a status update for this. (9/2015)
+
228 Cross-certifying identity keys with onion keys
This proposal signs each server's identity key with its onion
@@ -460,6 +543,8 @@ v
fixes an annoying gap in our key authentication. I have it coded
up in my #12498 branch, targetting 0.2.7. (2/2015)
+ Implemented; should mark as CLOSED. (9/2015)
+
229 Further SOCKS5 extensions
Here's a nice idea for how we can support a new SOCKS5 protocol
@@ -478,6 +563,9 @@ v
sure we'll be able to build thee, though: implementating proposal
220 above seems cleverer to me. (2/2015)
+ Proposal 220 is in progress, and will retroactively SUPERSEDE this
+ one. (9/2015)
+
232 Pluggable Transport through SOCKS proxy [OPEN]
Arturo Filastò wrote this proposal for chaining pluggable
@@ -527,6 +615,9 @@ v
DirServer. He has an implementation, possibly for 0.2.6 or 0.2.7,
in ticket #12538. (2/2015)
+ Compare to proposal 185; it may supersede that one. Review again
+ and mark as accepted maybe? (9/2015)
+
238 Better hidden service stats from Tor relays [DRAFT]
Here's an important one that needs many eyes. George Kadianakis,
@@ -536,6 +627,8 @@ v
sensitive intermediate results. This has an implementation in
0.2.6 and should probably be marked closed. (2/2015)
+ Indeed, mark as closed. (9/2015)
+
239 Consensus Hash Chaining [DRAFT]
Here's the start of a good idea that Andrea Shepard wrote up (with
@@ -546,6 +639,9 @@ v
improvements and had good questions (thanks, Leif and Sebastian G!)
(2/2015)
+ Needs revisions while we still remember what those revisions are.
+ (9/2015)
+
240 Early signing key revocation for directory authorities [DRAFT]
This one is another Andrea+Nick collaboration about certificate
@@ -554,6 +650,9 @@ v
circulation as fast as possible. Peter Palfrader on tor-dev had
some ideas for making this better. (2/2015)
+ Needs revisions while we still remember what those revisions are.
+ (9/2015)
+
241 Resisting guard-turnover attacks [DRAFT]
I wrote this one with good ideas from Aaron Johnson and Rob
@@ -565,11 +664,27 @@ v
paranoia. So, this proposal could use more analysis. (2/2015)
-Since last time:
+TAKE ANOTHER LOOK AT THESE:
- Proposal 140 and 227 have been implemented and closed.
+242 Better performance and usability for the MyFamily option [OPEN]
+243 Give out HSDir flag only to relays with Stable flag [OPEN]
- Proposal 215 was implemented and closed
+ (I think we impleented this one! Mark as FINISHED?)
- Proposals 230 through 241 are new.
+244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [DRAFT]
+
+ (Mark as ACCEPTED?)
+
+245 Deprecating and removing the TAP circuit extension protocol [DRAFT]
+246 Merging Hidden Service Directories and Introduction Points [OPEN]
+247 Defending Against Guard Discovery Attacks using Vanguards [DRAFT]
+248 Remove all RSA identity keys [DRAFT]
+249 Allow CREATE cells with >505 bytes of handshake data [DRAFT]
+250 Random Number Generation During Tor Voting [DRAFT]
+251 Padding for netflow record resolution reduction [DRAFT]
+252 Single Onion Services [DRAFT]
+
+
+Since last time:
+ Proposals 242-252 are new.
