Allow tor hidden services to delegate to operational public keys
The public key for a tor hidden service should be able to sign/delegate to a lower security "operational" key that actually executes all the ongoing protocol operations for that hidden service.
That way, you can air gap your hidden service key, and not lose your .onion address if/when a hidden server is compromised.
Activity
changed milestone to %Tor: unspecified
Trac:
Description: The public key for a tor hidden service should be able to sign/delegate to a lower security "operational" key that actually executes all the ongoing protocol operations for that hidden service.That way, you can air graph your hidden service key, and not lose your .onion address if/when a hidden server is compromised.
to
The public key for a tor hidden service should be able to sign/delegate to a lower security "operational" key that actually executes all the ongoing protocol operations for that hidden service.
That way, you can air gap your hidden service key, and not lose your .onion address if/when a hidden server is compromised.
One significant design decision when implementing this feature will be how to handle rollovers in the operational key. Three types of solutions would be (1) delegations that expire after a standard period of time; (2) having the client poll for revocations; (3) letting the hidden service key push revocations.
(3) sounds most elegant but I don't understand the hidden service descriptor DHT sufficiently to know whether it could be implemented in an easy and reliable way.
(1) is a total pain for hidden service operators that should be avoided if possible.
One way that (2) could be implemented is that hidden service descriptors could include a second, ordinary .onion address that may be polled for revocation information.
Replying to pde:
One significant design decision when implementing this feature will be how to handle rollovers in the operational key. Three types of solutions would be (1) delegations that expire after a standard period of time; (2) having the client poll for revocations; (3) letting the hidden service key push revocations.
(3) sounds most elegant but I don't understand the hidden service descriptor DHT sufficiently to know whether it could be implemented in an easy and reliable way.
(1) is a total pain for hidden service operators that should be avoided if possible.
One way that (2) could be implemented is that hidden service descriptors could include a second, ordinary .onion address that may be polled for revocation information.
Our current HSDir system stores hidden service descriptors only in memory, and only for up to 48 hours (normally only about 24 hours, and I wouldn't count on being able to republish the same descriptor for more than about 12 hours). The only option that might be backwards-compatible with our current HS directory system is (1), and that's not actually so bad (you would need only one or two pre-computed signed descriptors for each 12-hour period).
I'm inclined to stick with (1) even when we design a new HS protocol and directory system -- the space cost for enough information to reconstitute a ‘delegation certificate’ should be quite tiny.
Under scheme (1), where the hidden service key is airgapped, and a set of pre-computed, signed descriptors for the operational key is stored on the operational server, the tricky question is "how large should that pre-computed set of descriptors be?".
If it's small, the service operator will have to frequently use their airgapped system to make new descriptors and install them on the operational system.
If it's large, then an attacker who compromises the operational system will be able to keep control (or at least partial control?) of the hidden service for an extended period of time.
Designs (2) and (3) have the virtue that the operator does not need to ferry data between their airgapped and operational systems, unless and until the operational system is compromised.
I was about to propose the same. "Allow revocation of hidden service keys."
That feature is useful if anyone hosts a hidden service on remote server not under his control. If remote server ever gets compromised one way or another (hacked, malicious, court order, whatever), the user has a chance to revoke his key and start fresh.
(1) is a real pain, inconvenient and should be avoided unless you want to see less hidden services in future.
(1) is also unnecessary when it's unlikely that the hidden service key gets compromised, i.e. in case Tor runs on a different physical system than the server software.
My suggestion: When the hidden service key is created, create a master public key and an operational key. The master key can at any time revoke the operational key. All keys (master key, operational key) get stored in the usual folder. Warn and advise the user to move the master key to multiple encrypted backups.
Make it an optional feature.
Users who made a backup of the master key can create revocation keys and new public keys.
If they didn't care to move the master key, the hidden service is lost.
This way it's user friendly, flexible and secure.
Trac:
Cc: N/A to adrelanos@riseup.net
4 years without activity.
This ticket seems to have move to a "revocation key scheme" topic. We do have the concept of master key that can be kept offline in prop224. There is a TODO note in the proposal to have a revocation scheme in section 1.7. Nothing defined but we know it should be done somehow.
We should open a ticket when we'll address revocation because that might need a proposal and possibly some more research. Please re-open if unsatisfied with those reasons.
Trac:
Severity: N/A to Normal
Sponsor: N/A to None
Status: new to closed
Resolution: N/A to invalid
Reviewer: N/A to N/Amentioned in issue #3523 (moved)
moved to tpo/core/tor#3507 (closed)
