[tor-commits] [torspec/master] Give the rsa1024-relay-id-migration.txt proposal a number
nickm at torproject.org
nickm at torproject.org
Tue Apr 8 18:47:40 UTC 2014
commit 8bc6db6a9f8ac4eb3d85cfe574653b1ef8f255d3
Author: Nick Mathewson <nickm at 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.
-
-
More information about the tor-commits
mailing list