Re: [tor-dev] Proposal 230: How to change RSA1024 relay identity keys

[Nicholas Hopper <hopper@xxxxxxxxxx>]

On Tue, Apr 8, 2014 at 1:50 PM, Nick Mathewson <nickm@xxxxxxxxxxxxxx> wrote:
> Filename: 230-rsa1024-relay-id-migration.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.
s/value/valid

>    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.

possibly: bw authority weights?

>       * No longer accept any routers descriptors signed by the old
>         identity.

To clarify here: does "router[s] descriptors signed by the old
identity" include the old-id field?  That is, in case an identity key
is compromised is there a race to claim the old-id mapping?  If not,
how should the authorities/clients treat a pair of descriptors
claiming the mapping?

> 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.

I guess it's possible a relay operator could shoot themselves in the
foot here by causing some inconsistent state between these three
files.  I guess at worst, though, this should again be a case where
the window of vulnerability is small, so very few (or possibly no)
relays would lose their history this way.

-- 
------------------------------------------------------------------------
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
------------------------------------------------------------------------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev