Re: [tor-dev] A Proposal for a hidden service revocation system

Hi Adrien,

Good job on writing up a draft for this proposal! It looks good!

On 07/03/15 21:33, Adrien Johnson wrote:

Filename: xxx-rend-revoke.txt Title: Hidden Service Revocation Author: Adrien 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.

-- snip --

4.1 Basic Support

    For the Tor network to support hidden service revocations at a

basic level, a large proportion of hidden service directories must recognize that a hidden service descriptor with zero introductory points has the special meaning of being a revocation. These hidden service directories must not allow a current unexpired revocation descriptor to be replaced by a non-revocation descriptor (so called 'un-revocation'). In all other ways, treatment of a revocation descriptor is identical to treatment of a non-revocation descriptor for a hidden service.

    [NOTE: Maybe we want a more explicitly requested revocation?

Using a zero introductory point descriptor as a revocation has the advantage of being backward-compatible with older directory software, which will be able to accept and propagate the revocation to other more up-to-date directories, even though the older directories will not provide protection against un-revoking a hidden service if the attacker delivers an un-revocation descriptor to them directly.

    Is there a need for zero introductory point descriptors in any

other case? If a hidden service previously published introductory points and it now no longer can be contacted at those points, and it does not have any new introductory points, it is unreachable. Publishing a descriptor announcing all zero of its introductory points will not change its reachability, though it may slightly reduce wasted effort by tor nodes attempting to reach it.]

The current rend-spec allows for hidden service's to publish descriptors without any introduction points. I think it would much better to add an explicit 'revoked' line to the revocation descriptor.

I've done a quick test and it looks like relays already accept hidden service descriptors containing undefined fields. As such implementing it as such should be backward-compatible with previous version of Tor.

    4.1.1 Steps required to add support

        1) If current code results in hidden services publishing zero-
        introductory point descriptors, this is blocked to prevent
        accidental revocation. I would love to get this in 0.2.6.

        2) If a modification is needed in step 1, then a grace period
        is given for hidden service operators to update their
        software. This grace period does not have to be long, we can

move onto step 3 relatively fast, since the only penalty for accidental revocation step 3 would create is forcing the hidden service to upgrade their software, and the hidden service being unreachable for a maximum of 25 hours (lifetime of a descriptor) after the hidden service upgrades.

        3) Hidden service directories are modified to not allow a
        current unexpired revocation descriptor to be replaced by an
        un-revocation descriptor. Basic support for revocation is

achieved!

        4) A long upgrade grace period is now given. The vast majority
        of hidden services should be using software which includes the
        modifications made in step 1

        5) Expanded revocation capabilities may be added, as described
        below.

4.2 Expanded Capabilities

    4.2.1 Cache of revoked services

        A Tor node which tried to connect to a hidden service in the

past and discovered that the service was revoked should remember that revocation and refuse to connect indefinitely, even if the revocation ceases to be broadcast in the future.

The client should not keep local records of the hidden services that they have accessed. I think the client should only store the descriptor as normal in their local descriptor cache.

    4.2.2 Presentation to the user

        If an onion proxy that detects the user tried to visit a

revoked service, this information should be presented to the user out-of-band. I.E not in a way that could be mistaken for a hidden service which is only temporarily unreachable, or as information sent by the service. This could be done via a system level popup, or a taskbar notification. The presentation should be strongly distinguished from a hidden service which is simple unreachable.

A control port event should be defined to signal to a controller that the accessed hidden service has been revoked. The controller (TorButton etc.) could then notify the user is an appropriate way.

    4.2.3 Automatic hijacking detection/revocation

        Tor hidden service software could have a mode to detect if

another party is using the hidden service private key to publish descriptors for that service. If the hidden service operator configures it, the Tor hidden service software could immediately begin to broadcast the revocation for that service.

This may be possible, but I think it would be simpler and safer to implement "hijacking" detection outside of little-t-tor.

It practice, it may be difficult to ensure that a client actually receives a revocation descriptor. Firstly this protocol won't work very well until enough relays upgrade to version implementing this protocol.

Additionally with the current implementation of hidden services, an attacker who has compromised the HS key could position their relays to be the HSDir's for the revoked hidden service. They could then provide client's with only a standard descriptor and impersonate the HS. In practice it may be possible for a revocation service to to watch for this type of behaviour.

Thanks for putting this together. The best solution is of course of hidden service operators their service key safe in the first place!

Regards Donncha