231-migrate-authority-rsa1024-ids.txt

Filename: 231-migrate-authority-rsa1024-ids.txt
Title: Migrating authority RSA1024 identity keys
Authors: Nick Mathewson
Created: 8 April 2014
Target: 0.2.?
Status: Obsolete

Note: Obsoleted by Ed25519 ID keys; superseded by 240 and 256.

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.