Write guide about using offline ed25519 keys on relays
Hello,
tor-0.2.7.2-alpha introduced the ability for relays to store their master keys offline.
If we actually want people to use this feature, it would be nice if we made some sort of guide for relay operators and send it to [tor-relays] or something.
Getting more people to use it soon will also help us weed out any bugs or issues with this feature.
Activity
changed milestone to %Tor: 0.2.8.x-final
I will start to write an easy and complete FAQ. My concern is with people not reading it more than how to write it. I want to make sure that if someone wants to use this feature, he read the documention before (which is why I want to keep the FAQ page small, simple, explicit even for non technical people, so that it will be read entirely).
Can we create an ascii-armor version of the encrypted ed25519 master id key easily?
I would like to offer the possibility to store it in as many different places as possible: sending it in an email, printing it in a QR code or saving a small image of the QR code somwhere, storing it in a cloud service (maybe with an optional additional layer of PGP encryption for operators who also use PGP). Given the fact that most of relays are probably run in datacenters, I don't think many operators can plug a storage media in the servers and cut/paste the key, so they will have to export it thorugh the internet via a secure channel.
While discussing with nickm usuability, I was thinking to make Tor ask some questions when started (no ed25519 key found, generate one? encrypt it? what SigningKeyLifetime? [...]) and to make it also at the same time noninteractive, use the defaults if no input from the user within 'n' seconds. Thinking more about this approach, I don't think it would be a great idea, as it would require more code and will also maybe make the operator 'curious' and probably use the feature without reading the entire documentation or understanding how it works exactly. Operators playing with this feature in a wrong way will affect the network in a bad way. If an operator is interested into using this feature, a big clear FAQ / HOWTO page will be available and we should limit the possibility for someone using this feature without knowing about it or reading the instructions.
I see 3 major points an operator needs to pay attention to:
-
Don't forget to attend to the relay within the SigningKeyLifetime period and create a new signing key + cert. Keeping the master ID key offline will not work for relays which run for long time unattended. Better not use this feature if you don't have time to attend to the relay as required by the SigningKeyLifetime period;
-
Don't lose the master id key - save backups in multiple places. Understand that losing this means losing the identity of the relay forever. Would require to start a new fresh relay from scratch;
-
Use a strong password and remember it;
(maybe) don't even allow to use silly passwords like and require min. 8 chars length, at least one upper case, one lower case, one number and one symbol. The tradeoff with this is that we could force the operator to use a more complicated password which will be easier to forget (and forgetting the password == losing the master id key forever).
-
Trac:
Cc: N/A to s7r@sky-ip.org
Replying to s7r:
Can we create an ascii-armor version of the encrypted ed25519 master id key easily?
You should ask Nick about why we don't just make the files on disk ascii-armored by default, like we do for the old-style keys. That seems useful for all the reasons we ascii-armored the other keys (and doubly so for anything with the word 'offline' used near it, for those people who enjoy printing to paper).
I'll handle this. I am just waiting to close #17127 (moved) to release the full documentation, but I could release the incomplete version earlier if needed. Opinions?
Trac:
Owner: N/A to s7r
Cc: s7r@sky-ip.org to N/A
Status: new to assigned
It would be better to have something good now than something perfect later. I don't know how long #17127 (moved) will take.
Trac:
Severity: N/A to NormalReplying to s7r:
I'll handle this. I am just waiting to close #17127 (moved) to release the full documentation, but I could release the incomplete version earlier if needed. Opinions?
vote for something over nothing: +1
Here is something very simple and explicit I think. We should convert the content into html code to fill in nicely with the rest of website and include links to this guide page on:
-
The FAQ page, under the key related frequently asked questions, as mentioned in #17021 (moved)
-
Run a relay/bridge installation guides.
-
Tor wiki maybe?
Plain text content: https://gist.github.com/gits7r/a53c46d7e3f0e9030369
Trac:
Status: assigned to needs_review-
Ok, I spent about a half hour cleaning this up and turning it into a wiki page. It still needs to actually link to the random pages you mentioned in-line, but it's a lot better: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys
Can you fix that to actually link to the pages you want to link, and make sure that everything is properly formatted? Then we can post the link to the tor-relays list.
It might also be nice if we also update https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity to mention using offline keys (and link to that page) instead of (or in addition to?) the ramdisk and key removal suggestions.
Trac:
Status: needs_review to needs_revisionLooks good to me. Cleaned the links, but for them to actually work we need to close #17021 (moved).
I have linked it in https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity as well.
This tickets seems resolved to me. @s7r, are you satisfied with it. Do we consider this done?
Trac:
Reviewer: N/A to N/A@dgoulet yes, it's resolved. Had to remove #16680 (moved) as child ticket so we can close this. They are not so related and #16680 (moved) can wait a little more.
Trac:
Resolution: N/A to fixed
Status: needs_revision to closedmentioned in issue #16680 (moved)
mentioned in issue #17021 (moved)
moved to tpo/core/tor#16645 (closed)
mentioned in issue tpo/core/tor#16680 (closed)
