[tor-commits] [torspec/master] Add draft for proposal for removing ID keys.

nickm at torproject.org nickm at torproject.org
Wed Jul 15 17:36:16 UTC 2015

commit 342f21ba5cb15a5c6f7ff4f383c5ea51a3d549fc
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Jul 15 13:36:05 2015 -0400

    Add draft for proposal for removing ID keys.
 proposals/000-index.txt                   |    2 +
 proposals/248-removing-rsa-identities.txt |   88 +++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 3e160d0..2a63b04 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -168,6 +168,7 @@ Proposals by number:
 245  Deprecating and removing the TAP circuit extension protocol [DRAFT]
 246  Merging Hidden Service Directories and Introduction Points [OPEN]
 247  Defending Against Guard Discovery Attacks using Vanguards [DRAFT]
+248  Remove all RSA identity keys [DRAFT]
 Proposals by status:
@@ -196,6 +197,7 @@ Proposals by status:
    244  Use RFC5705 Key Exporting in our AUTHENTICATE calls
    245  Deprecating and removing the TAP circuit extension protocol
    247  Defending Against Guard Discovery Attacks using Vanguards
+   248  Remove all RSA identity keys
    131  Help users to verify they are using Tor
    190  Bridge Client Authorization Based on a Shared Secret
diff --git a/proposals/248-removing-rsa-identities.txt b/proposals/248-removing-rsa-identities.txt
new file mode 100644
index 0000000..93584c0
--- /dev/null
+++ b/proposals/248-removing-rsa-identities.txt
@@ -0,0 +1,88 @@
+Filename: 248-removing-rsa-identities.txt
+Title: Remove all RSA identity keys
+Authors: Nick Mathewson
+Created: 15 August 2015
+Status: Draft
+1. Summary
+   With, all relays will have Ed25519 identity keys.  Old
+   identity keys are 1024-bit RSA, which should not really be considered
+   adequate.  In proposal 220, we describe a migration path to start
+   using Ed25519 keys.  This proposal describes an additional migration
+   path, for finally removing our old Ed25519 keys.
+   See also proposal 245, which describes a migration path away from the
+   old TAP RSA1024-based circuit extension protocol.
+1.1. Steps of migration
+   Phase 1. Prepare for routers that do not advertise their RSA
+     identities, by teaching clients and relays and other dependent
+     software how to handle them.  Reject such routers at the authority
+     level.
+   Phase 2. Once all supported routers and clients are updated to phase
+     1, we can accept routers at the authority level which lack RSA
+     keys.
+   Phase 3. Once all authorities accept routers without RSA keys, we can
+     finally remove RSA keys from relays.
+2. Accepting descriptors without RSA identities
+   We make the following changes to the descriptor format:
+   If an ed25519 key and signature are present, then these elements may
+   be omitted: "fignerprint", "signing-key", "router-signature".  They
+   must either be all present or all absent.  If they are all absent,
+   then the router has no RSA identity key.
+   Authorities MUST NOT accept routers descriptors of this form in phase
+   1.
+3. Accepting handshakes without RSA identities
+   When performing a new version of our link handshake, only the Ed25519
+   key and certificates and authentication need to be performed.  If the
+   link handshake is performed this way, it is accepted as
+   authenticating the route with an ed25519 key but no RSA key.
+   A circuit extension EXTEND2 cell may contain an Ed25519 identity but
+   not an RSA identity.  In this case, the relay should connect the
+   circuit to any connection with the correct ed25519 identity,
+   regardless of RSA identity.  If an EXTEND2 cell contains an RSA
+   identity fingerprint, however, its the relay receiving it should not
+   connect to any relay that has a different RSA identity or that has no
+   identity, even if the Ed25519 identity does match.
+4. UI updates
+   In phase 1 we can update our UIs to refer to all relays that have
+   Ed25519 keys by their Ed25519 keys.  We can update our configuration
+   and control port interfaces so that they accept Ed keys as well as
+   RSA keys.
+   During phase 1, we should warn about identifying any dual-identity
+   relays by their Ed identity alone.
+   For backward compatibility, we should consider a default that refers
+   to referring to Ed25519 relays by the first 160 bits of their key.
+   This would allow many controller-based tools to work transparently
+   with the new key types.
+5. Changes to external tools
+   This is the big one.  We need a relatively comprehensive list of
+   tools we can break with the above changes.  Anything that refers to
+   relays by SHA1(RSA1024_id) will need to be able to remember and use
+   an Ed25519 key instead.
+5. Testing
+   Before going forward with phase 2 and phase 3, we need to verify that
+   we did phase 1 correctly.  To do so, we should create a small
+   temporary testing network, and verify that it works correctly as we
+   make the phase 2 and phase 3 changes.

More information about the tor-commits mailing list