Proposal: Hidden Service Revocation

Filename: xxx-rend-revoke.txt Title: Hidden Service Revocation Author: Nathaniel Johnson Created: 2015-03-04 Status: Draft

Hidden service operators need to be able to revoke trust in their hidden service if they know or suspect their hidden service secret key has been compromised.

1. Motivation

A Hidden service operator can determine that the hidden service secret keyis compromised in several ways today. Forensic traces of intrusion may bedetected on the hidden service server, or valid signed descriptors for theservice may be published by someone other than the legitimate operator in atraffic hijacking attack.

Even though it is possible for the operator to detect a hidden service key iscompromised, there is no satisfactory way for a hidden service operator tonotify its users of this fact. The hidden service may displaya message to its users warning of the compromise and directing them to a newsupposedly uncompromised .onion domain, but a user has no way to knowwhether such a message was posted by the legitimate hidden service operatoror a hijacker.

A revocation system where anyone possessing the hidden service secret keycan revoke trust in the key solves this problem.

2. Overview

This revocation system is built on the hidden service directory system. Arevocation takes the form of a hidden service descriptor which provides noway to contact the hidden service (i.e. zero introductory points), andcontains a "revoked" line of the following format

"revoked" NL

[At most once]

If present in a hidden service descriptor which also contains zerointroductory points, indicates that this is a revocation of the hiddenservice.

A hidden service directory which receives a revocation descriptor andverifies its signature should discard any non-revocation descriptors itpossesses for that hidden service, and should propagate the revocationthrough the hidden service directory system as normal.

Crucially, a hidden service directory which possesses a revocationdescriptor for a hidden service and receives a newer, valid descriptor forthat hidden service which is not a revocation descriptor MUST retain therevocation descriptor and MUST discard the newer non-revocation descriptor.This is the only change needed to support this revocation system at abasic level today.

3. Design considerations

3.1 Revocation lifetime

Ideally, a revocation should be permanent. The Tor network wouldideally remember forever that a hidden service has been revoked, andthis would provide the maximum possible protection to the users of thehidden service against imposter services.

However, a permanent (or even just long-lived) revocation in the hiddenservice directories present problems:

1. Increased memory and bandwidth requirements on the Tor networkcompared to a normal hidden service descriptor. For non-malicious use,this may not really be a problem, since once a service is revoked, therewould be only a trickle of requests for updated information about it(from visitors who have not already found out it was revoked). Howeverfor a malicious user who attacks the Tor network by flooding it withhidden service descriptors for fake hidden services, any increasedlifetime of a revocation descriptor over a normal descriptor representsa multiplication of their attack power.

2. For next generation hidden services as described in224-rend-spec-ng.txt, a revocation which lasts longer than one blindedsigning key validity period weakens the privacy protection againstcorrelation which is provided by rotating blinded signing keys. If arevocation were - for any amount of time - not expected to besigned by the current normal blinded signing key for that service, butinstead a separate 'blinded revocation signing key', then users seekingto check the revocation status of that service before visiting wouldhave to make two requests for a hidden service descriptor: one to see ifthere is a revocation descriptor published by that service, and one tosee if there is a normal descriptor published by that service. A malicious hidden service directory (or group of directories) could usethis correlation to determine which hidden service descriptors belong tothe same hidden service between blinded signing key rotations.

Implementing a long-lived hidden service revocation at the client level,a cache of previously seen revoked hidden services for example, woulddisclose the user's browsing history to anyone who examined it, and istherefore not a good solution either.

For these reasons, revocations which last no longer thana normal hidden service descriptor, and which the operator musttherefore constantly broadcast, are the safest option for implementinghidden service revocations.

Short lived revocations have the advantage that the Tor network does notneed to make any hard-and-fast judgement about how long it is worthwhileto remember a hidden service has been revoked, the hidden serviceoperator can make that judgement for themselves and broadcast therevocation for as long the operator feels hijacking and impersonationis a concern.

If the operator is unable to maintain (or fears they will be unable tomaintain) a revocation broadcast for an appropriate amount of time,they can disclose their private key to a 3rd party service who willbroadcast the revocation on the operator's behalf. An operator wouldwant to employ several of these services, since if only one service hadthe private key, and if they were malicious, they could ceasebroadcasting the revocation and instead use the key to set up animpostor service.

Despite these minor difficulties that short-lived revocations impose,they are still a major improvement to the security of the Tor network.

3.2 Side note on the shape of a 3rd party Revocation Broadcast Service

Though it is outside the scope of this specification,I envision these 3rd party key revocation services being simple websiteswhere anyone can upload a hidden service private key and the websitewill broadcast the revocation indefinitely. They could employ simpleabuse-mitigation like CAPCHAs or IP ratelimiting over the clearnet toprevent mass-upload of keys. This should keeps costs low enough thatthese revocations services would operate for free.

4. Implementation

4.1 Basic Support

For the Tor network to support hidden service revocations at a basiclevel, a large proportion of hidden service directories must recognizethat a hidden service descriptor with zero introductory points and able"revoked" line has the special meaning of being a revocation.These hidden service directories must not allow a current unexpiredrevocation descriptor to be replaced by a non-revocation descriptor(so called 'un-revocation'). In all other ways, treatment of arevocation descriptor is identical to treatment of a non-revocationdescriptor for a hidden service.

4.1.1 Steps required to add support

1. Hidden service directories are modified to recognize the formatof a revocation descriptor, and prevent revocation descriptors frombeing superseded by a non-revocation descriptor for the sameservice. Basic support from the core software is achieved!

2. The ability to broadcast revocations is implemented.

3. Expanded revocation capabilities may be added, as describedbelow.

4.2 Expanded Capabilities

4.2.1 Presentation to the user

If an onion proxy that detects the user tried to visit a revokedservice, this information should be presented to the userout-of-band. I.E not in a way that could be mistaken for a hiddenservice which is only temporarily unreachable, or as informationsent by the service. This could be done via a system level popup, ora taskbar notification. The presentation should be stronglydistinguished from a hidden service which is simple unreachable.

4.2.2 Automatic hijacking detection/revocation

Tor hidden service software could have a mode to detect if anotherparty is using the hidden service private key to publish descriptorsfor that service. If the hidden service operator configures it,the Tor hidden service software could immediately begin to broadcastthe revocation for that service.

[Per Donncha's feedback, both of these should probably be delegatedto control software, with tor itself simply exposing an eventwhenever a revoked site is encountered or a new valid descriptoris published, and the external controller will take care of notifyingthe user or detecting if any separate tor node is publishing descriptorsfor the same service.]

5. Future Compatibility with Next Generation Hidden Services

Next generation Tor hidden services require a modifiedrevocation system because the hidden service master secret key is betterprotected, and does not need to be constantly live on the hidden service tornode. The day-to-day operation of the service is carried out by a pre-loadedset of changing subordinate descriptor signing keys, which expire after aset time (25 hours by default). If descriptor signing keys are compromised,they can be used to hijack traffic and impersonate the hidden service,but only until the descriptor signing keys expire. So there is an additionalneed for a way to revoke descriptor signing keys and provide new ones,without permanently revoking trust in the hidden service.

Also, theft of descriptor signing keys should not allow an attacker torevoke the master secret key.

The revocation permissions would looks something like the following.(Blinded signing keys are equivalent to the master secret key forrevocation purposes because if an attacker obtains any blinded signingsecret key, they can mathematically derive the master secret key.)

1. Current descriptor signing key can revoke current descriptor signing key.

2. Master secret key can revoke any descriptor signing key and provide a newdescriptor signing key for that time-period.

3. Master secret key is the only one that can revoke master secret key.

[TODO: Sketch out implementation later]

Trac:
Username: Nathaniel