commit 99a660b440a46ba9e25c02273acda6dfd36c7ff7 Author: Nick Mathewson <nickm@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.