commit 8bc6db6a9f8ac4eb3d85cfe574653b1ef8f255d3 Author: Nick Mathewson <nickm@torproject.org> Date: Tue Apr 8 14:44:33 2014 -0400 Give the rsa1024-relay-id-migration.txt proposal a number --- proposals/230-rsa1024-relay-id-migration.txt | 83 ++++++++++++++++++++++++++ proposals/xxx-rsa1024-relay-id-migration.txt | 83 -------------------------- 2 files changed, 83 insertions(+), 83 deletions(-) diff --git a/proposals/230-rsa1024-relay-id-migration.txt b/proposals/230-rsa1024-relay-id-migration.txt new file mode 100644 index 0000000..d2f3aff --- /dev/null +++ b/proposals/230-rsa1024-relay-id-migration.txt @@ -0,0 +1,83 @@ +Filename: 230-rsa1024-relay-id-maigration.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. + + 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. + + * No longer accept any routers descriptors signed by the old + identity. + + 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]. + +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. + + Sixty days after the stored timestamp, the router deletes the + "old_id_key_migration" file and stops including its contents in + the descriptor. + + diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt deleted file mode 100644 index 45166f0..0000000 --- a/proposals/xxx-rsa1024-relay-id-migration.txt +++ /dev/null @@ -1,83 +0,0 @@ -Filename: xxx-rsa1024-relay-id-maigration.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. - - 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. - - * No longer accept any routers descriptors signed by the old - identity. - - 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]. - -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. - - Sixty days after the stored timestamp, the router deletes the - "old_id_key_migration" file and stops including its contents in - the descriptor. - -