Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Sun, Aug 17, 2014 at 8:40 PM, Sebastian Hahn <hahn.seb@xxxxxx> wrote:
> Hi Nick,
>
> On 25 Feb 2014, at 17:18, Nick Mathewson <nickm@xxxxxxxxxxxxxx> wrote:
>>   To mirror the way that authority identity keys work, we'll fully
>>   support keeping Ed25519 identity keys offline; they'll be used to
>>   sign long-ish term signing keys, which in turn will do all of the
>>   heavy lifting.  A signing key will get used to sign the things that
>>   RSA1024 identity keys currently sign.
>
> There was a discussion of this point on tor-talk just now. s7r (one
> of the nice support people) was also present, maybe he will follow up
> here as well.
>
> Basically, the operational complexity of doing this seems to be
> under-appreciated here, and we're wondering if the added code
> complexity can possibly be worth it. Maybe we should ask some of the
> super big relays to weigh in.

Hi, Sebastian!

To clarify here, since I don't think I explained well enough in the
proposal: this feature is meant to allow offline identity keys, but
not require them.  If the identity key is online and readable by the
Tor process, Tor should generate new signing keys as needed.

I think that having a multi-layer key structure like this is possibly
beneficial, even for environments where managing signing key rotation
is too hard.  For example:

  * The identity key could be owned by a different user or kept in a
separate VM (or maybe a hardware component? ha, ha.) and only the
signing keys could be delivered to the Tor user.  This is the kind of
thing that an OS or package could manage.

  * In systems with fine-grained filesystem access controls, the Tor
process could drop the ability to read the identity key at startup,
right after making sure that it has enough signing keys.  Or, the
identity key could be isolated in a process that does nothing but
generate signing keys and their certificates.

  * Even without access controls, we could arrange for identity keys
to be purged from RAM whenever we're not actually generating a signing
key, and handled by a separate process that doesn't talk to the
network. This would make it impossible for a memory-exposure bug (like
heartbleed) to expose identity keys.

All that said, I'd also like to know what relay admins think of the
practicalities here.

best wishes,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev