Opened 4 years ago

Closed 3 years ago

#16645 closed task (fixed)

Write guide about using offline ed25519 keys on relays

Reported by: asn Owned by: s7r
Priority: Very High Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-relay, doc, review-group-7
Cc: tyseom Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorU-can

Description

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.

Child Tickets

TicketStatusOwnerSummaryComponent
#16769closednickmadd two new functions when manually calling --keygen for better managementCore Tor/Tor

Change History (21)

comment:1 Changed 4 years ago by s7r

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

comment:2 Changed 4 years ago by s7r

Cc: s7r@… added

comment:3 in reply to:  1 Changed 4 years ago by arma

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

comment:4 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:5 Changed 4 years ago by nickm

Points: medium
Priority: normalcritical

comment:6 Changed 4 years ago by s7r

Cc: s7r@… removed
Owner: set to s7r
Status: newassigned

I'll handle this. I am just waiting to close #17127 to release the full documentation, but I could release the incomplete version earlier if needed. Opinions?

comment:7 Changed 4 years ago by nickm

Severity: Normal

It would be better to have something good now than something perfect later. I don't know how long #17127 will take.

comment:8 Changed 3 years ago by tyseom

Cc: tyseom added

comment:9 in reply to:  6 Changed 3 years ago by cypherpunks

Replying to s7r:

I'll handle this. I am just waiting to close #17127 to release the full documentation, but I could release the incomplete version earlier if needed. Opinions?

vote for something over nothing: +1

comment:10 Changed 3 years ago by s7r

Status: assignedneeds_review

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:

  1. The FAQ page, under the key related frequently asked questions, as mentioned in #17021
  1. Run a relay/bridge installation guides.
  1. Tor wiki maybe?

Plain text content:
https://gist.github.com/gits7r/a53c46d7e3f0e9030369

comment:11 Changed 3 years ago by mikeperry

Status: needs_reviewneeds_revision

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.

comment:12 Changed 3 years ago by cypherpunks

There was an error in the renewal section, restart/reload is not required. I changed that.

comment:13 Changed 3 years ago by s7r

Looks good to me. Cleaned the links, but for them to actually work we need to close #17021.

I have linked it in https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity as well.

comment:14 Changed 3 years ago by nickm

Sponsor: SponsorU-can

comment:15 Changed 3 years ago by nickm

Keywords: TorCoreTeam201605 added

These 0.2.8 items really should get handled in May. Or earlier.

comment:16 Changed 3 years ago by nickm

Calling all non-needs_information tickets for May.

comment:17 Changed 3 years ago by isabela

Points: medium3

comment:18 Changed 3 years ago by nickm

Keywords: TorCoreTeam201605 removed

Remove "TorCoreTeam201605" keyword. The time machine is broken.

comment:19 Changed 3 years ago by nickm

Keywords: review-group-7 added

comment:20 Changed 3 years ago by dgoulet

This tickets seems resolved to me. @s7r, are you satisfied with it. Do we consider this done?

comment:21 Changed 3 years ago by s7r

Resolution: fixed
Status: needs_revisionclosed

@dgoulet yes, it's resolved. Had to remove #16680 as child ticket so we can close this. They are not so related and #16680 can wait a little more.

Note: See TracTickets for help on using tickets.