[tor-commits] [torspec/master] Draft proposal for how to migrate a bunch of router identity keys
nickm at torproject.org
nickm at torproject.org
Tue Apr 8 18:47:40 UTC 2014
Author: Nick Mathewson <nickm at torproject.org>
Date: Mon Apr 7 19:02:53 2014 -0400
Draft proposal for how to migrate a bunch of router identity keys
We might decide to do this as part of a CVE-2014-0160 response.
proposals/xxx-rsa1024-relay-id-migration.txt | 83 ++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt
new file mode 100644
@@ -0,0 +1,83 @@
+Title: How to change RSA1024 relay identity keys
+Authors: Nick Mathewson
+Created: 7 April 2014
+1. Intro and motivation
+ Some times, a relay would like to migrate from one RSA1024
+ identity key to another without losing its previous status.
+ This is especially important because proposal 220 ("Migrate
+ server identity keys to Ed25519") is not yet implemented, and so
+ server identity keys are not kept offline. So when an OpenSSL
+ bug like CVE-2014-0160 makes memory-reading attacks a threat to
+ identity keys, we need a way for routers to migrate ASAP.
+ This proposal does not cover migrating RSA1024 OR identity keys
+ for authorities.
+ I propose that when a relay changes its identity key, it should
+ include a "old-identity" field in its server descriptor for 60 days
+ after the migration. This old-identity would include the
+ old RSA1024 identity, a signature of the new identity key
+ with the old one, and the date when the migration occurred.
+ This field would appear as an "old-id" field in microdescriptors,
+ containin a SHA1 fingerprint of the old identity key, if the
+ signature turned out to be value.
+ Authorities would store old-identity => new-identity mappings,
+ * Treat history information (wfu, mtbf, [and what else?]) from
+ old identities as applying to new identities instead.
+ * No longer accept any routers descriptors signed by the old
+ Clients would migrate any guard entries for the old identity to
+ the new identity.
+ (This will break clients connections for clients who try to
+ connect to the old identity key before learning about the new
+ one, but the window there won't be large for any single router.)
+3. Descriptor format details
+ Router descriptors may contain these new elements:
+ "old-rsa1024-id-key" NL RSA_KEY NL
+ Contains an old RSA1024 identity key. If this appears,
+ old-rsa1024-id-migration must also appear. [At most once]
+ "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL
+ Contains a signature of:
+ The bytes "RSA1024 ID MIGRATION" [20 bytes]
+ The ISO-TIME field above as an 8 byte field [8 bytes]
+ A SHA256 hash of the new identity [32 bytes]
+ If this appears, "old-rsa1024-id-key" must also appear.
+ [At most once].
+ To use this feature, a router should rename its secret_id_key
+ file to secret_id_key_OLD. The first time that Tor starts and
+ finds a secret_id_key_OLD file, it generates a new ID key if one
+ is not present, and generates the text of the old-rsa-1024-id-key
+ and old-rsa1024-id-migration fields above. It stores them in a
+ new "old_id_key_migration" file, and deletes the
+ secret_id_key_OLD file. It includes them in its desecriptors.
+ Sixty days after the stored timestamp, the router deletes the
+ "old_id_key_migration" file and stops including its contents in
+ the descriptor.
More information about the tor-commits