On Tue, Apr 8, 2014 at 1:50 PM, Nick Mathewson nickm@torproject.org wrote:
Filename: 230-rsa1024-relay-id-migration.txt Title: How to change RSA1024 relay identity keys Authors: Nick Mathewson Created: 7 April 2014 Target: 0.2.? Status: Draft
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.
Design
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, containing a SHA1 fingerprint of the old identity key, if the signature turned out to be value.
s/value/valid
Authorities would store old-identity => new-identity mappings, and:
* Treat history information (wfu, mtbf, [and what else?]) from old identities as applying to new identities instead.
possibly: bw authority weights?
* No longer accept any routers descriptors signed by the old identity.
To clarify here: does "router[s] descriptors signed by the old identity" include the old-id field? That is, in case an identity key is compromised is there a race to claim the old-id mapping? If not, how should the authorities/clients treat a pair of descriptors claiming the mapping?
Interface
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.
I guess it's possible a relay operator could shoot themselves in the foot here by causing some inconsistent state between these three files. I guess at worst, though, this should again be a case where the window of vulnerability is small, so very few (or possibly no) relays would lose their history this way.