Opened 7 years ago

Closed 2 years ago

#3507 closed enhancement (invalid)

Allow tor hidden services to delegate to operational public keys

Reported by: pde Owned by: rransom
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop224 tor-hs
Cc: adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor: None

Description (last modified by arma)

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.

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by arma

Description: modified (diff)

comment:2 Changed 7 years ago by 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.

comment:3 in reply to:  2 Changed 7 years ago by rransom

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.

comment:4 Changed 7 years ago by pde

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.

comment:5 Changed 7 years ago by nickm

Keywords: needs-proposal added
Milestone: Tor: unspecified

comment:6 Changed 6 years ago by proper

Cc: adrelanos@… added

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.

comment:7 Changed 6 years ago by nickm

Keywords: tor-hs added

comment:8 Changed 6 years ago by nickm

Component: Tor Hidden ServicesTor

comment:9 Changed 3 years ago by nickm

Keywords: prop224 added; needs-proposal removed

comment:10 Changed 2 years ago by dgoulet

Resolution: invalid
Severity: Normal
Sponsor: None
Status: newclosed

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.

Note: See TracTickets for help on using tickets.