commit df51057a3f437ca69df026c0da66a3e280bb44e8 Author: Nick Mathewson <nickm@torproject.org> Date: Tue Apr 8 15:20:27 2014 -0400 Proposal 231: Migrating authority RSA1024 identity keys --- proposals/000-index.txt | 2 + proposals/231-migrate-authority-rsa1024-ids.txt | 68 +++++++++++++++++++++++ 2 files changed, 70 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 4e74fed..bec7a14 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -151,6 +151,7 @@ Proposals by number: 228 Cross-certifying identity keys with onion keys [OPEN] 229 Further SOCKS5 extensions [DRAFT] 230 How to change RSA1024 relay identity keys [DRAFT] +231 Migrating authority RSA1024 identity keys [DRAFT] Proposals by status: @@ -171,6 +172,7 @@ Proposals by status: 225 Strawman proposal: commit-and-reveal shared rng 229 Further SOCKS5 extensions 230 How to change RSA1024 relay identity keys [for 0.2.?] + 231 Migrating authority RSA1024 identity keys [for 0.2.?] NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret diff --git a/proposals/231-migrate-authority-rsa1024-ids.txt b/proposals/231-migrate-authority-rsa1024-ids.txt new file mode 100644 index 0000000..88c78e1 --- /dev/null +++ b/proposals/231-migrate-authority-rsa1024-ids.txt @@ -0,0 +1,68 @@ +Filename: 231-migrate-authority-rsa1024-ids.txt +Title: Migrating authority RSA1024 identity keys +Authors: Nick Mathewson +Created: 8 April 2014 +Target: 0.2.? +Status: Draft + +1. Intro and motivation + + We'd like for RSA1024 identity keys to die out entirely. But we + may need to migrate authority identity keys before that happens. + + 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 authorities to migrate ASAP. + + Migrating authority ID keys is a trickier problem than migrating + router ID keys, since the authority RSA1024 keys are hardwired in the + source. We use them to authenticate encrypted OR connections to + authorities that we use to publish and retrieve directory + information. + + This proposal does not cover migrating RSA1024 OR identity keys for + other nodes; for that, see proposal 230. + +2. Design + + When an authority is using a new RSA1024 key, it retains the old one + in a "legacy_link_id_key" file. It uses this key to perform link + protocol handshakes at its old address:port, and it uses the new key + to perform link protocol handshakes at a new address:port. + + This should be sufficient for all clients that expect the old + address:port:fingerprint to work, while allowing new clients to use + the correct address:port:fingerprint. + + Authorities will sign their own router descriptors with their new + identity key, and won't advertise the old port or fingerprint at all + in their descriptors. This shouldn't break anything, so far as I + know. + +3. Implementation + + We'll have a new flag on an ORPort: "LegacyIDKey". It implies + NoAdvertise. If it is present, we use our LegacyIDKey for that + ORPort and that ORPort, for all of: + + * The TLS certificate chains used in the v1 and v2 link protocol + handshake. + + * The certificate chains and declared identity in the v3 link + handshake. + + * Accepting ntor cells. + +4. Open questions + + On ticket #11448, Robert Ransom suggests that authorities may need to + publish extra server descriptors for themselves, signed with the old + identity key too. We should investigate whether clients will + misbehave if they can't find such descriptors. + + If that's the case, authorities should generate these descriptors, + but not include them in votes or the consensus; or if they are + included, don't assign them flags that will get them used. +