From 8909adaa97645d8fd4292df2efd46dc5e1a5c2d4 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Sat, 21 Apr 2007 17:48:50 +0000 Subject: r12489@catbus: nickm | 2007-04-21 13:48:39 -0400 The ten thousandth Tor commit: add two new proposals (one from Mike Perry about randomized path length, and one from me about simplifyin authority operation) and expand and/or refine serveral older ones. Most notable there are changes to 103 that will allow us to make authorities more resistant to key compromise. svn:r10000 --- proposals/113-fast-authority-interface.txt | 80 ++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 proposals/113-fast-authority-interface.txt (limited to 'proposals/113-fast-authority-interface.txt') diff --git a/proposals/113-fast-authority-interface.txt b/proposals/113-fast-authority-interface.txt new file mode 100644 index 0000000..4982908 --- /dev/null +++ b/proposals/113-fast-authority-interface.txt @@ -0,0 +1,80 @@ +Filename: 113-fast-authority-interface.txt +Title: Simplifying directory authority administration +Version: $Revision: 12412 $ +Last-Modified: $Date: 2007-04-16T19:11:29.511998Z $ +Author: Nick Mathewson +Created: +Status: Open + +Overview + +The problem: + + Administering a directory authority is a pain: you need to go through + emails and manually add new nodes as "named". When bad things come up, + you need to mark nodes (or whole regions) as invalid, badexit, etc. + + This means that mostly, authority admins don't: only 2/4 current authority + admins actually bind names or list bad exits, and those two have often + complained about how annoying it is to do so. + + Worse, name binding is a common path, but it's a pain in the neck: nobody + has done it for a couple of months. + +Digression: who knows what? + + It's trivial for Tor to automatically keep track of all of the + following information about a server: + name, fingerprint, IP, last-seen time, first-seen time, declared + contact. + + All we need to have the administrator set is: + - Is this name/fingerprint pair bound? + - Is this fingerprint/IP a bad exit? + - Is this fingerprint/IP an invalid node? + - Is this fingerprint/IP to be rejected? + + The workflow for authority admins has two parts: + - Periodically, go through tor-ops and add new names. This doesn't + need to be done urgently. + - Less often, mark badly behaved serves as badly behaved. This is more + urgent. + +Possible solution #1: Web-interface for name binding. + + Deprecate use of the tor-ops mailing list; instead, have operators go to a + webform and enter their server info. This would put the information in a + standardized format, thus allowing quick, nearly-automated approval and + reply. + +Possible solution #2: Self-binding names. + + Peter Palfrader has proposed that names be assigned automatically to nodes + that have been up and running and valid for a while. + +Possible solution #3: Self-maintaining approved-routers file + + Mixminion alpha has a neat feature where whenever a new server is seen, + a stub line gets added to a configuration file. For Tor, it could look + something like this: + + ## First seen with this key on 2007-04-21 13:13:14 + ## Stayed up for at least 12 hours on IP 192.168.10.10 + #RouterName AAAABBBBCCCCDDDDEFEF + + (Note that the implementation needs to parse commented lines to make sure + that it doesn't add duplicates, but that's not so hard.) + + To add a router as named, administrators would only need to uncomment the + entry. This automatically maintained file could be kept separately from a + manually maintained one. + + This could be combined with solution #2, such that Tor would do the hard + work of uncommenting entries for routers that should get Named, but + operators could override its decisions. + +Possible solution #4: A separate mailing list for authority operators. + + Right now, the tor-ops list is very high volume. There should be another + list that's only for dealing with problems that need prompt action, like + marking a router as !badexit. -- cgit v1.2.3-54-g00ecf