|
|
@@ -0,0 +1,99 @@
|
|
|
+Filename: 136-legacy-keys.txt
|
|
|
+Title: Mass authority migration with legacy keys
|
|
|
+Author: Nick Mathewson
|
|
|
+Created: 13-May-2008
|
|
|
+Status: Open
|
|
|
+
|
|
|
+Overview:
|
|
|
+
|
|
|
+ This document describes a mechanism to change the keys of more than
|
|
|
+ half of the directory servers at once without breaking old clients
|
|
|
+ and caches immediately.
|
|
|
+
|
|
|
+Motivation:
|
|
|
+
|
|
|
+ If a single authority's identity key is believed to be compromised,
|
|
|
+ the solution is obvious: remove that authority from the list,
|
|
|
+ generate a new certificate, and treat the new cert as belonging to a
|
|
|
+ new authority. This approach works fine so long as less than 1/2 of
|
|
|
+ the authority identity keys are bad.
|
|
|
+
|
|
|
+ Unfortunately, the mass-compromise case is possible if there is a
|
|
|
+ sufficiently bad bug in Tor or in any OS used by a majority of v3
|
|
|
+ authorities. Let's be prepared for it!
|
|
|
+
|
|
|
+ We could simply stop using the old keys and start using new ones,
|
|
|
+ and tell all clients running insecure versions to upgrade.
|
|
|
+ Unfortunately, this breaks our cacheing system pretty badly, since
|
|
|
+ caches won't cache a consensus that they don't believe in. It would
|
|
|
+ be nice to have everybody become secure the moment they upgrade to a
|
|
|
+ version listing the new authority keys, _without_ breaking upgraded
|
|
|
+ clients until the caches upgrade.
|
|
|
+
|
|
|
+ So, let's come up with a way to provide a time window where the
|
|
|
+ consensuses are signed with the new keys and with the old.
|
|
|
+
|
|
|
+Design:
|
|
|
+
|
|
|
+ We allow directory authorities to list a single "legacy key"
|
|
|
+ fingerprint in their votes. Each authority may add a single legacy
|
|
|
+ key. The format for this line is:
|
|
|
+
|
|
|
+ legacy-dir-key FINGERPRINT
|
|
|
+
|
|
|
+ We describe a new consensus method for generating directory
|
|
|
+ consensuses. This method is consensus method "3".
|
|
|
+
|
|
|
+ When the authorities decide to use method "3" (as described in 3.4.1
|
|
|
+ of dir-spec.txt), for every included vote with a legacy-dir-key line,
|
|
|
+ the consensus includes an extra dir-source line. The fingerprint in
|
|
|
+ this extra line is as in the legacy-dir-key line. The ports and
|
|
|
+ addresses are in the dir-source line. The nickname is as in the
|
|
|
+ dir-source line, with the string "-legacy" appended.
|
|
|
+
|
|
|
+ [We need to include this new dir-source line because the code
|
|
|
+ won't accept or preserve signatures from authorities not listed
|
|
|
+ as contributing to the consensus.]
|
|
|
+
|
|
|
+ Authorities using legacy dir keys include two signatures on their
|
|
|
+ consensuses: one generated with a signing key signed with their real
|
|
|
+ signing key, and another generated with a signing key signed with
|
|
|
+ another signing key attested to by their identity key. These
|
|
|
+ signing keys MUST be different. Authorities MUST serve both
|
|
|
+ certificates if asked.
|
|
|
+
|
|
|
+Process:
|
|
|
+
|
|
|
+ In the event of a mass key failure, we'll follow the following
|
|
|
+ (ugly) procedure:
|
|
|
+ - All affected authorities generate new certificates and identity
|
|
|
+ keys, and circulate their new dirserver lines. They copy their old
|
|
|
+ certificates and old broken keys, but put them in new "legacy
|
|
|
+ key files".
|
|
|
+ - At the earliest time that can be arranged, the authorities
|
|
|
+ replace their signing keys, identity keys, and certificates
|
|
|
+ with the new compromised versions, and update to the new list
|
|
|
+ of dirserer lines.
|
|
|
+ - They add an "V3DirAdvertiseLegacyKey 1" option to their torrc.
|
|
|
+ - Now, new consensuses will be generated using the new keys, but
|
|
|
+ the results will also be signed with the old keys.
|
|
|
+ - Clients and caches are told they need to upgrade, and given a
|
|
|
+ time window to do so.
|
|
|
+ - At the end of the time window, authorities remove the
|
|
|
+ V3DirAdvertiseLegacyKey option.
|
|
|
+
|
|
|
+Notes:
|
|
|
+
|
|
|
+ It might be good to get caches to cache consensuses that they do not
|
|
|
+ believe in. I'm not sure the best way of how to do this.
|
|
|
+
|
|
|
+ It's a superficially neat idea to have new signing keys and have
|
|
|
+ them signed by the new and by the old authority identity keys. This
|
|
|
+ breaks some code, though, and doesn't actually gain us anything,
|
|
|
+ since we'd still need to include each signature twice.
|
|
|
+
|
|
|
+ It's also a superficially neat idea, if identity keys and signing
|
|
|
+ keys are compromised, to at least replace all the signing keys.
|
|
|
+ I don't think this achieves us anything either, though.
|
|
|
+
|
|
|
+
|
Nick Mathewson