From a70c68181d04e8f487a45c25babdbbb971ff3148 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 14 May 2008 18:53:02 +0000 Subject: Actually add proposal 136: authority identity key migration mechanisms svn:r14615 --- proposals/136-legacy-keys.txt | 99 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 proposals/136-legacy-keys.txt (limited to 'proposals/136-legacy-keys.txt') diff --git a/proposals/136-legacy-keys.txt b/proposals/136-legacy-keys.txt new file mode 100644 index 0000000..908142b --- /dev/null +++ b/proposals/136-legacy-keys.txt @@ -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. + + -- cgit v1.2.3-54-g00ecf