Add three older documents removed from tor.git

3 files changed, 354 insertions, 0 deletions

diff --git a/attic/authority-policy.txt b/attic/authority-policy.txt
new file mode 100644
index 0000000..7072082
--- /dev/null
+++ b/attic/authority-policy.txt
@@ -0,0 +1,89 @@
+
+0. Overview.
+
+   This document contains various informal policies for how to operate
+   a directory authority, how to choose new ones, etc.
+
+1. How to pick a new directory authority.
+
+   Here's our current guidelines for how to pick new directory
+   authorities.
+
+   (These won't ever be formal criteria -- we need to keep this flexible
+   so we can adapt to new situations.)
+
+   o Stability:
+     - Must be a low-downtime Tor server (computer as well as network).
+     - Must have a static IP.
+     - The operator must have been running a stable Tor server for at least
+       3 months.
+     - Must intend for this server to stick around for the next 12 months
+       or more.
+     - Must not hibernate.
+     - Should not be an exit node (as this increases the risk both of
+       downtime and of key compromise).
+
+   o Performance:
+     - Must have sufficient bandwidth: at least 10mbit/s symmetric,
+       though in practice the inbound traffic can be considerably less.
+
+   o Availability:
+     - Must be available to upgrade within a few days in most cases.
+       (While we're still developing Tor, we periodically find bugs that
+       impact the whole network and require authority upgrades.)
+     - Should have a well-known way to contact the administrator
+       via PGP-encrypted message.
+
+   o Integrity:
+     - Must promise not to censor or attack the network and users.
+     - Should be run by somebody that Tor (i.e. Roger) knows.
+     - Should be widely regarded as fair/trustworthy, or at least
+       known, by many people.
+     - If somebody asks you to backdoor or change your server, legally or
+       otherwise, you will fight it to the extent of your abilities. If
+       you fail to fight it, you must shut down the Tor server and notify
+       us that you have.
+
+   o Diversity
+     - We should avoid situations that make it likelier for multiple
+       authority failures to happen at the same time.  Therefore...
+       - It's good when authorities are not all in the same country.
+       - It's good when authorities are not all in the same jurisdictions.
+       - It's good when authorities are not all running the same OS.
+       - It's good when authorities are not all using the same ISP.
+       - It's good when authorities are not all running the same
+         version of Tor.
+       - No two authorities should have the same operator.
+     - Maximal diversity, however, is not always practical.  Sometimes,
+       for example, there is only one version of Tor that provides a
+       given consensus generation algorithm.
+     - A small group of authorities with the same country/jurisdiction/OS is
+       not a problem, until that group's size approaches quorum (half the
+       authorities).
+
+2. How to choose the recommended versions
+
+  The policy, in a nutshell, is to not remove versions without a good
+  reason. So this means we should recommend all versions except:
+
+  - Versions that no longer conform to the spec. That is, if they wouldn't
+    actually interact correctly with the current Tor network.
+  - Versions that have known security problems.
+  - Versions that have frequent crash or assert problems.
+  - Versions that harm the performance or stability of the current Tor
+    network or the anonymity of other users. For example, a version
+    that load balances wrong, or a version that hammers the authorities
+    too much.
+
+
+> some use the slight variant of requiring a *good* reason.
+> excellent reasons include "there's a security flaw"
+> good reasons include "that crashes every time you start it. you would think
++tor is dumb if you tried to use that version and think of it as tor."
+> good reasons include "those old clients do their load balancing wrong, and
++they're screwing up the whole network"
+> reasons include "the old one is really slow, clients should prefer the new
++one"
+> i try to draw the line at 'good reasons and above'
+
+
diff --git a/attic/torel-design.txt b/attic/torel-design.txt
new file mode 100644
index 0000000..610cbe2
--- /dev/null
+++ b/attic/torel-design.txt
@@ -0,0 +1,181 @@
+Design For A Tor DNS-based Exit List
+
+Status:
+
+  This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes.
+  See http://exitlist.torproject.org/ for an implementation.
+
+Why?
+
+  It's useful for third parties to be able to tell when a given connection
+  is coming from a Tor exit node.  Potential applications range from
+  "anonymous user" cloaks on IRC networks like oftc, to networks like
+  Freenode that apply special authentication rules to users from these
+  IPs, to systems like Wikipedia that may want to make a priority of
+  _unblocking_ shared IPs more liberally than non-shared IPs, since shared
+  IPs presumably have non-abusive users as well as abusive ones.
+
+  Since Tor provides exit policies, not every Tor server will connect to
+  every address:port combination on the Internet.  Unless you're trying to
+  penalize hosts for supporting anonymity, it makes more sense to answer
+  the fine-grained question "which Tor servers will connect to _me_?" than
+  the coarse-grained question "which Tor servers exist?"  The fine-grained
+  approach also helps Tor server ops who share an IP with their Tor
+  server: if they want to access a site that blocks Tor users, they
+  can exclude that site from their exit policy, and the site can learn
+  that they won't send it anonymous connections.
+
+  Tor already ships with a tool (the "contrib/exitlist" script) to
+  identify which Tor nodes might open anonymous connections to any given
+  exit address.  But this is a bit tricky to set up, so only sites like
+  Freenode and OFTC that are dedicated to privacy use it.
+  Conversely, providers of some DNSEL implementations are providing
+  coarse-grained lists of Tor hosts -- sometimes even listing servers that
+  permit no exit connections at all.  This is rather a problem, since
+  support for DNSEL is pretty ubiquitous.
+
+
+How?
+
+  Keep a running Tor instance, and parse the cached-routers and
+  cached-routers.new files as new routers arrive.  To tell whether a given
+  server allows connections to a certain address:port combo, look at the
+  definitions in dir-spec.txt or follow the logic of the current exitlist
+  script. If bug 405 is still open when you work on this
+  (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll
+  probably want to extend it to look at only the newest descriptor for
+  each server, so you don't use obsolete exit policy data.
+
+  FetchUselessDescriptors would probably be a good torrc option to enable.
+
+  If you're also running a directory cache, you get extra-fresh
+  information.
+
+
+The DNS interface
+
+  Standard DNSEL, if I understand right, looks like this: There's some
+  authoritative name server for foo.example.com.  You want to know if
+  1.2.3.4 is in the list, so you query for an A record for
+  4.3.2.1.foo.example.com.  If the record exists and has the value
+  127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list.  If you get an NXDOMAIN
+  error, 1.2.3.4 is not in the list.  If you ask for a domain name outside
+  of the foo.example.com zone, you get a Server Failure error[RFC 1035].
+
+  Assume that the DNSEL answers queries authoritatively for some zone,
+  torhosts.example.com.  Below are some queries that could be supported,
+  though some of them are possibly a bad idea.
+
+
+  Query type 1: "General IP:Port"
+
+    Format:
+        {IP1}.{port}.{IP2}.ip-port.torhosts.example.com
+
+    Rule:
+        Iff {IP1} is a Tor server that permits connections to {port} on
+        {IP2}, then there should be an A record with the value 127.0.0.2.
+
+    Example:
+        "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the
+        value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1
+        that allows connections to port 80 on 1.2.3.4.
+
+    Example use:
+        I'm running an IRC server at w.x.y.z:9999, and I want to tell
+        whether an incoming connection is from a Tor server.  I set
+        up my IRC server to give a special mask to any user coming from
+        an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com.
+
+        Later, when I get a connection from a.b.c.d, my ircd looks up
+        "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see
+        if it's a Tor server that allows connections to my ircd.
+
+
+  Query type 2: "IP-port group"
+
+    Format:
+        {IP}.{listname}.list.torhosts.example.com
+
+    Rule:
+        Iff this Tor server is configured with an IP:Port list named
+        {listname}, and {IP} is a Tor server that permits connections to
+        any member of {listname}, then there exists an A record.
+
+    Example:
+        Suppose torhosts.example.com has a list of IP:Port called "foo".
+        There is an A record for 4.3.2.1.foo.list.torhosts.example.com
+        if and only if 1.2.3.4 is a Tor server that permits connections
+        to one of the addresses in list "foo".
+
+    Example use:
+        Suppose torhosts.example.com has a list of hosts in "examplenet",
+        a popular IRC network.  Rather than having them each set up to
+        query the appropriate "ip-port" list, they could instead all be
+        set to query a central examplenet.list.torhosts.example.com.
+
+    Problems:
+        We'd be better off if each individual server queried about hosts
+        that allowed connections to itself.  That way, if I wanted to
+        allow anonymous connections to foonet, but I wanted to be able to
+        connect to foonet from my own IP without being marked, I could add
+        just a few foonet addresses to my exit policy.
+
+
+  Query type 3: "My IP, with port"
+
+    Format:
+        {IP}.{port}.me.torhosts.example.com
+
+    Rule:
+        An A record exists iff there is a tor server at {IP} that permits
+        connections to {port} on the host that requested the lookup.
+
+    Example:
+        "4.3.2.1.80.me.torhosts.example.com" should have an A record if
+        and only if there is a Tor server at 1.2.3.4 that allows
+        connections to port 80 of the querying host.
+
+    Example use:
+        Somebody wants to set up a quick-and-dirty Tor detector for a
+        single webserver: just point them at 80.me.torhosts.example.com.
+
+    Problem:
+        This would be easiest to use, but DNS gets in the way. If you
+        create DNS records that give different results depending on who is
+        asking, you mess up caching.  There could be a fix here, but might
+        not.
+
+
+  RECOMMENDATION: Just build ip-port for now, and see what demand is
+  like.  There's no point in building mechanisms nobody wants.
+
+Web interface:
+
+  Should provide the same data as the dns interface.
+
+Other issues:
+
+  After a Tor server op turns off their server, it stops publishing server
+  descriptors. We should consider that server's IP address to still
+  represent a Tor node until 48 hours after its last descriptor was
+  published.
+
+  30-60 minutes is not an unreasonable TTL.
+
+  There could be some demand for address masks and port lists. Address
+  masks wider than /8 make me nervous here, as do port ranges.
+
+  We need an answer for what to do about hosts which exit from different
+  IPs than their advertised IP. One approach would be for the DNSEL
+  to launch periodic requests to itself through all exit servers whose
+  policies allow it -- and then see where the requests actually come from.
+
+References:
+
+  [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for
+  E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November
+  2005.
+
+  [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+  Specification", RFC 1035, November 1987.
diff --git a/attic/v3-authority-howto.txt b/attic/v3-authority-howto.txt
new file mode 100644
index 0000000..e4470e8
--- /dev/null
+++ b/attic/v3-authority-howto.txt
@@ -0,0 +1,84 @@
+
+                    How to add a v3 directory authority.
+
+What we'll be doing:
+
+   We'll be configuring your Tor server as a v3 directory authority,
+   generating a v3 identity key plus certificates, and adding your v3
+   identity fingerprint to the list of default directory authorities.
+
+The steps:
+
+0) Make sure you're running ntp, and that your time is correct.
+
+   Make sure you have Tor version at least r12724. In the short term,
+   running a working authority may mean running the latest version of
+   Tor from SVN trunk. Later on, we hope that it will become easier
+   and you can just run a recent development release (and later still,
+   a recent stable release).
+
+1) First, you'll need a certificate.  Run ./src/tools/tor-gencert to
+   generate one.
+
+   Run tor-gencert in a separate, very secure directory.  Maybe even on
+   a more secure computer.  The first time you run it, you will need to
+   run it with the --create-identity-key option to make a v3 authority
+   identity key.  Subsequent times, you can just run it as-is.
+
+   tor-gencert will make 3 files:
+
+      authority_identity_key -- THIS IS VERY SECRET AND VERY SENSITIVE.
+        DO NOT LEAK IT.  DO NOT LOSE IT.
+
+      authority_signing_key -- A key for signing votes and v3 conensuses.
+
+      authority_certificate -- A document authenticating your signing key
+         with your identity-key.
+
+   You will need to rotate your signing key periodically.  The current
+   default lifetime is 1 year.  We'll probably take this down to a month or
+   two some time soon.  To rotate your key, run tor-gencert as before,
+   but without the --create-identity-key option.
+
+2) Copy authority_signing_key and authority_certificate to your Tor keys
+   directory.
+
+   For example if your data directory is /var/lib/tor/, you should run
+     cp authority_signing_key authority_certificate /var/lib/tor/keys/
+
+   You will need to repeat this every time you rotate your certificate.
+
+3) Tell your Tor to be a v3 authority by adding these lines to your torrc:
+
+   AuthoritativeDirectory 1
+   V3AuthoritativeDirectory 1
+
+4) Now your authority is generating a networkstatus opinion (called a
+   "vote") every period, but none of the other authorities care yet. The
+   next step is to get a Tor developer (likely Roger or Nick) to add
+   your v3 identity fingerprint to the default list of dirservers.
+
+   First, you need to learn your authority's v3 identity fingerprint.
+   It should be in your authority_certificate file in a line like:
+
+     fingerprint 3041632465FA8847A98B2C5742108C72325532D9
+
+   One of the Tor developers then needs to add this fingerprint to
+   the add_default_trusted_dirservers() function in config.c, using
+   the syntax "v3ident=<fingerprint>". For example, if moria1's new v3
+   identity fingerprint is FOO, the moria1 dirserver line should now be:
+
+     DirServer moria1 v1 orport=9001 v3ident=FOO 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441
+
+   The v3ident item must appear after the nickname and before the IP.
+
+5) Once your fingerprint has been added to config.c, we will try to
+   get a majority of v3 authorities to upgrade, so they know about you
+   too. At that point your vote will automatically be included in the
+   networkstatus consensus, and you'll be a fully-functioning contributing
+   v3 authority.
+
+   Note also that a majority of the configured v3 authorities need to
+   agree in order to generate a consensus: so this is also the point
+   where extended downtime on your server means missing votes.
+