commit b9264adbbf46f659f8c4ae22e75bef883d08e435 Author: Nick Mathewson nickm@torproject.org Date: Tue Oct 27 11:50:04 2015 -0400

[256] Key revocation for relays and authorities --- proposals/000-index.txt | 4 +- proposals/256-key-revocation.txt | 242 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 245 insertions(+), 1 deletion(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 9debfba..d9a161d 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -176,6 +176,7 @@ Proposals by number: 253 Out of Band Circuit HMACs [DRAFT] 254 Padding Negotiation [DRAFT] 255 Controller features to allow for load-balancing hidden services [DRAFT] +256 Key revocation for relays and authorities [OPEN]

Proposals by status: @@ -213,7 +214,7 @@ Proposals by status: 201 Make bridges report statistics on daily v3 network status requests [for 0.2.4.x] 202 Two improved relay encryption protocols for Tor cells 209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+] - 210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+] + 210 Faster Headless Consensus Bootstrapping [for 0.2.8.x+] 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] 226 "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" @@ -224,6 +225,7 @@ Proposals by status: 237 All relays are directory servers [for 0.2.7.x] 242 Better performance and usability for the MyFamily option 246 Merging Hidden Service Directories and Introduction Points + 256 Key revocation for relays and authorities ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/256-key-revocation.txt b/proposals/256-key-revocation.txt new file mode 100644 index 0000000..7f21c1c --- /dev/null +++ b/proposals/256-key-revocation.txt @@ -0,0 +1,242 @@ +Filename: 256-key-revocation.txt +Title: Key revocation for relays and authorities +Authors: Nick Mathewson +Created: 27 October 2015 +Status: Open + +1. Introduction + + This document examines the different kinds of long-lived public keys + in Tor, and discusses a way to revoke each. + + The kind of keys at issue are: + + * Authority identity keys + * Authority signing keys + + * OR identity keys (ed25519) + * OR signing keys (ed25519) + * OR identity keys (RSA) + + Additionally, we need to make sure that all other key types, if they + are compromised, can be replaced or rendered unusable. + +2. When to revoke keys + + Revoking keys should happen when the operator of an authority or + relay believes that the key has been compromised, or has a + significant risk of having been compromised. In this proposal we + deliberately leave this decision up to the authority/relay operators. + + (If a third party believes that a key has been compromised, they + should attempt to get the key-issuing party to revoke their key. If + that can't be done, the uncompromised authorities should block the + relay or de-list the authority in question.) + + Our key-generation code (for authorities and relays) should generate + preemptive revocation documents at the same time it generates the + original keys, so that operators can retain those documents in the + event that access to the original keys is lost. The operators should + keep these revocation documents private and available enough so that + they can issue the revocation if necessary, but nobody else can. + + Additionally, the key generation code should be able to generate + retrospective revocation documents for existing keys and + certificates. (This approach can be more useful when a subkey is + revoked, but the operator still has ready access to the issuing key.) + +3. Authority keys + + Authority identity keys are the most important keys in Tor. They are + kept offline and encrypted. They are used to sign authority signing + keys, and for no other purpose. + + Authority signing keys are kept online. They are authenticated by + authority identity keys, and used to sign votes and consensus + documents. + + (For the rest of section 2, all keys mentioned will be authority keys.) + +3.1. Revocation certificates for authorities + + We add the following extensions to authority key certificates (see + dir-spec.txt section 3.1), for use in key revocation. + + "dir-key-revocation-type" SP "master" | "signing" NL + + Specifies which kind of revocation document this is. + + If dir-key-revocation is absent, this is not a revocation. + + [At most once] + + "dir-key-revocation-notes" SP (any non-NL text) NL + + An explanation of why the key was revoked. + + Must be absent unless dir-key-revocation-type is set. + + [Any number of times] + + "dir-key-revocation-signing-key-unusable" NL + + Present if the signing key in this document will not actually be + used to sign votes and consensuses. + + [At most once] + + "dir-key-revoked-signing-key" SP DIGEST NL + + Fingerprints of signing keys being explicitly revoked by this + certificate. (All keys published before this one are _implicitly_ + revoked.) + + [Any number of times] + + "dir-key-revocation-published" SP YYYY-MM-DD SP HH:MM:SS NL + + The actual time when the revocation was generated. (Used since the + 'published' field in the certificate will lie; see below.) + + [at most once.] + + +3.2. Generating revocations + + Revocations for signing keys should be generated with: + * A 'published' time immediately following the published date on + the key that they are revoking. + * An 'expires' time at least 48 hours after the expires date on + the key that they are revoking, and at least one week in the + future. + + (Note that this ensures as-correct-as-possible behavior for existing + Tor clients and servers. For Tor versions before 0.2.6, having a + more recent published date than the older key will cause the revoked + key certificate to be removed by trusted_dirs_remove_old_certs() if + it is published at least 7 days in the past. For Tor versions 0.2.6 + or later, the interval is reduced to 2 days.) + + If generating a signing key revocation ahead of time, the revocation + document should include a dummy signing key, to be thrown away + immediately after it is generated and used to make the revocation + document. The "dir-key-revocation-signing-key-unusable" element + should be present. + + If generating a signing key revocation in response to an event, + the revocation document should include the new signing key to be + used. The "dir-key-revocation-signing-key-unusable" element + must be be absent. + + All replacement certificates generated for the lifetime of the + original revoked certificate should be generated as revocations. + + + + Revocations for master keys should be generated with: + * A 'published' time immediately following the published date on + the most recently generated certificate, if possible. + * An 'expires' time equal to 18 Jan 2038. (The next-to-last day + encodeable in time_t, to avoid Y2038 problems.) + * A dummy signing key, as above. + +3.3. Submitting revocations + + In the event of a key revocation, authority operators should + upload the revocation document to every other authority. + + If there is a replacement signing key, it should be included in the + authority's votes (as any new key certificate would be). + +3.4. Handling revocations + + We add these additional rules for caching and storing revocations on + Tor servers and clients. + * Master key revocations should be stored indefinitely. + * If we have a master key revocation, no other certificates for + that key should be fetched, stored, or served. + * If we have a master key revocation, we should replace any + DirAuthority entry for that master key with a 'null' entry -- an + authority with no address and no keys, from which nothing can be + downloaded and nothing can be trusted, but which still counts against + the total number of authorities. + + * Signing key revocations should be retained until their 'expires' + date. + * If we have a signing key revocation document, we should not trust + any signature generated with any key in an older signing key + certificates for the same master key. We should not serve such + key certificates. + * We should not attempt to fetch any certificate document matching + an <identity, signing> pair for which a revocation document exists. + + We add these additional rule for directory authorities: + + * When generating or serving a consensus document, an authority + should include a dir-source entry based on the most recent + revocation cert it has from an authority, unless that authority + has a more recent valid key cert. + + (This will require a new consensus method.) + + * When generating or serving a consensus document, if no valid + signature exists from a given authority, and that authority has + a currently valid key revocation document with a signing key in + it, it should include a bogus signature purporting to be made + with that signing key. (All-zeros is suggested.) + + (Doing this will make old Tor clients download the revocation + certificates.) + +4. Router identity key revocations + +4.1. RSA identity keys + + If the RSA key is compromised but the ed25519 identity and signing + keys are not, simply disable the router. Key pinning should take + care of the rest. + + (This isn't ideal when key pinning isn't deployed yet, but I'm + betting that key pinning comes online before this proposal does.) + +4.2. Ed25519 master identity keys + + (We use the data format from proposal 220, section 2.3 here.) + + To revoke a master identity key, create a revocation for the master + key and upload it to every authority. + + Authorities should accept these documents as meaning that the signing + key should never be allowed to appear on the Tor network. This can + be enforced with the key pinning mechanism. + +4.3. Ed25519 signing keys + + (We use the data format from proposal 220, section 2.3 here.) + + To revoke a signing key, include the revocation for every + not-yet-expired signing key in your routerinfo document, as in: + + "revoked-signing-key" SP Base64-Ed25519-Key NL + + Note that this doesn't need to be authenticated, since the newer + signing key certificate creates a trust path from the master + identity key to the the revocation. + + [Up to 32 times.] + + Upon receiving these entries, authorities store up to 32 such entries + per router per year. (If you have more than 32 keys compromised, + give up and take your router down. Start it with a new master key.) + + When voting, authorities include a "rev" line in the + microdescriptor for every revoked-signing-key in the routerinfo: + + "rev" SP "ed25519" SP Base64-Ed25519-Key NL + + (This will require a new microdescriptor version.) + + Upon receiving such a line in the microdescriptor, Tor instances MUST + NOT trust any signing key certificate with a matching key. + +