On Tue, Apr 8, 2014 at 1:50 PM, Nick Mathewson <[email protected]> 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 > > 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. > > 2. 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? > 4. 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. -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
