proposals/136-legacy-keys.txt

   1 Filename: 136-legacy-keys.txt
   2 Title: Mass authority migration with legacy keys
   3 Author: Nick Mathewson
   4 Created: 13-May-2008
   5 Status: Closed
   6 Implemented-In: 0.2.0.x
   7
   8 Overview:
   9
  10   This document describes a mechanism to change the keys of more than
  11   half of the directory servers at once without breaking old clients
  12   and caches immediately.
  13
  14 Motivation:
  15
  16   If a single authority's identity key is believed to be compromised,
  17   the solution is obvious: remove that authority from the list,
  18   generate a new certificate, and treat the new cert as belonging to a
  19   new authority.  This approach works fine so long as less than 1/2 of
  20   the authority identity keys are bad.
  21
  22   Unfortunately, the mass-compromise case is possible if there is a
  23   sufficiently bad bug in Tor or in any OS used by a majority of v3
  24   authorities.  Let's be prepared for it!
  25
  26   We could simply stop using the old keys and start using new ones,
  27   and tell all clients running insecure versions to upgrade.
  28   Unfortunately, this breaks our cacheing system pretty badly, since
  29   caches won't cache a consensus that they don't believe in.  It would
  30   be nice to have everybody become secure the moment they upgrade to a
  31   version listing the new authority keys, _without_ breaking upgraded
  32   clients until the caches upgrade.
  33
  34   So, let's come up with a way to provide a time window where the
  35   consensuses are signed with the new keys and with the old.
  36
  37 Design:
  38
  39   We allow directory authorities to list a single "legacy key"
  40   fingerprint in their votes.  Each authority may add a single legacy
  41   key.  The format for this line is:
  42
  43      legacy-dir-key FINGERPRINT
  44
  45   We describe a new consensus method for generating directory
  46   consensuses.  This method is consensus method "3".
  47
  48   When the authorities decide to use method "3" (as described in 3.4.1
  49   of dir-spec.txt), for every included vote with a legacy-dir-key line,
  50   the consensus includes an extra dir-source line.  The fingerprint in
  51   this extra line is as in the legacy-dir-key line.  The ports and
  52   addresses are in the dir-source line.  The nickname is as in the
  53   dir-source line, with the string "-legacy" appended.
  54
  55       [We need to include this new dir-source line because the code
  56       won't accept or preserve signatures from authorities not listed
  57       as contributing to the consensus.]
  58
  59   Authorities using legacy dir keys include two signatures on their
  60   consensuses: one generated with a signing key signed with their real
  61   signing key, and another generated with a signing key signed with
  62   another signing key attested to by their identity key.  These
  63   signing keys MUST be different.  Authorities MUST serve both
  64   certificates if asked.
  65
  66 Process:
  67
  68   In the event of a mass key failure, we'll follow the following
  69   (ugly) procedure:
  70      - All affected authorities generate new certificates and identity
  71        keys, and circulate their new dirserver lines.  They copy their old
  72        certificates and old broken keys, but put them in new "legacy
  73        key files".
  74      - At the earliest time that can be arranged, the authorities
  75        replace their signing keys, identity keys, and certificates
  76        with the new uncompromised versions, and update to the new list
  77        of dirserer lines.
  78      - They add an "V3DirAdvertiseLegacyKey 1" option to their torrc.
  79      - Now, new consensuses will be generated using the new keys, but
  80        the results will also be signed with the old keys.
  81      - Clients and caches are told they need to upgrade, and given a
  82        time window to do so.
  83      - At the end of the time window, authorities remove the
  84        V3DirAdvertiseLegacyKey option.
  85
  86 Notes:
  87
  88   It might be good to get caches to cache consensuses that they do not
  89   believe in.  I'm not sure the best way of how to do this.
  90
  91   It's a superficially neat idea to have new signing keys and have
  92   them signed by the new and by the old authority identity keys.  This
  93   breaks some code, though, and doesn't actually gain us anything,
  94   since we'd still need to include each signature twice.
  95
  96   It's also a superficially neat idea, if identity keys and signing
  97   keys are compromised, to at least replace all the signing keys.
  98   I don't think this achieves us anything either, though.
  99
 100