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.
1. Motivation
A Hidden service operator can determine that the hidden service
secret key
is compromised in several ways today. Forensic traces of intrusion
may be
detected on the hidden service server, or valid signed descriptors
for the
service may be published by someone other than the legitimate
operator in a
traffic hijacking attack. It is impossible for a compromised hidden
service
secret key to be used to hijack traffic in a way that is not
detectable by
the latter method.
Even though it is easy for the operator to detect a hidden service
key is
compromised, there is no satisfactory way for a hidden service
operator to
notify its users of this fact. The hidden service may display
a message to its users warning of the compromise and directing them
to a new
supposedly uncompromised .onion domain, but a user has no way to know
whether such a message was posted by the legitimate hidden service
operator
or a hijacker.
A revocation system where anyone possessing the hidden service
secret key
can revoke trust in the key solves this problem.
2. Overview
This revocation system is built on the hidden service directory
system. A
revocation takes the form of a hidden service descriptor which
provides no
way to contact the hidden service (i.e. zero introductory points).
A hidden service directory which receives a revocation descriptor and
verifies its signature should discard any non-revocation descriptors it
possesses for that hidden service, and should propagate the revocation
through the hidden service directory system as normal.
Crucially, a hidden service directory which possesses a revocation
descriptor for a hidden service and receives a newer, valid
descriptor for
that hidden service which is not a revocation descriptor MUST
retain the
revocation descriptor and MUST discard the newer non-revocation
descriptor.
This is the only change needed to support this revocation system at a
basic level today.
3. Design considerations
3.1 Revocation lifetime
Ideally, a revocation should be permanent. The Tor network would
ideally remember forever that a hidden service has been
revoked, and
this would provide the maximum possible protection to the users
of the
hidden service against imposter services.
Indeed, any tor node which becomes aware a hidden service has been
revoked should remember this information forever, and should
refuse to
connect to any hidden service which it knows was revoked in the
past
(unless the user disables this protection).
However, a permanent (or even just long-lived) revocation in
the hidden
service directories present problems:
1) Increased memory and bandwidth requirements on the Tor network
compared to a normal hidden service descriptor. For
non-malicious use,
this may not really be a problem, since once a service is
revoked, there
would be only a trickle of requests for updated information
about it
(from visitors who have not already found out it was revoked).
However
for a malicious user who attacks the Tor network by flooding it
with
hidden service descriptors for fake hidden services, any increased
lifetime of a revocation descriptor over a normal descriptor
represents
a multiplication of their attack power.
2) For next generation hidden services as described in
224-rend-spec-ng.txt, a revocation which lasts longer than one
blinded
signing key validity period weakens the privacy protection against
correlation which is provided by rotating blinded signing keys.
If a
revocation were - for any amount of time - not expected to be
signed by the current normal blinded signing key for that
service, but
instead a separate 'blinded revocation signing key', then users
seeking
to check the revocation status of that service before visiting
would
have to make two requests for a hidden service descriptor: one
to see if
there is a revocation descriptor published by that service, and
one to
see if there is a normal descriptor published by that service.
A malicious hidden service directory (or group of directories)
could use
this correlation to determine which hidden service descriptors
belong to
the same hidden service between blinded signing key rotations.
[NOTE: Not sure how easy correlation based on request volume
already
makes this attack if the attacker controls enough hidden server
directories to reliably monitor request volume between blinded
signing
key rotations. I suspect the real danger of long-lived revocations
compared to attacks based purely on request volume is that it lets
attackers easily "pick up a lost trail" if they managed to link a
revocation signing key and a normal blinded signing key at any time
in the past, whereas attacks based purely on request volume are
likely
to lose track of a service permanently when its descriptors
shift to
a directory the attacker does not control]
For these reasons, revocations which last no longer than
a normal hidden service descriptor, and which the operator must
therefore constantly broadcast, are the safest option for
implementing
hidden service revocations using hidden service descriptors.
Short lived revocations have the advantage that the Tor network
does not
need to make any hard-and-fast judgement about how long it is
worthwhile
to remember a hidden service has been revoked, the hidden service
operator can make that judgement for themselves and broadcast the
revocation for as long the operator feels hijacking and
impersonation
is a concern.
If the operator is unable to maintain (or fears they will be
unable to
maintain) a revocation broadcast for an appropriate amount of time,
they can disclose their private key to a 3rd party service who will
broadcast the revocation on the operator's behalf. An operator
would
want to employ several of these services, since if only one
service had
the private key, and if they were malicious, they could cease
broadcasting the revocation and instead use the key to set up an
impostor 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 Digression on the shape of a 3rd party Revocation Broadcast Service
Though it is outside the scope of this proposal,
I envision these 3rd party key revocation services being simple
websites
where anyone can upload a hidden service private key and the
website
will broadcast the revocation indefinitely. They could employ
simple
abuse-mitigation like CAPCHAs or IP ratelimiting over the
clearnet to
prevent mass-upload of keys. This should keeps costs low enough
that
these revocations services could operate for free.
Alternatively (or additionally), a distributed 3rd party revocation
service could be built into the Tor network by enclosing the
private
key in the revocation descriptor. This would allow anyone who
retrieves
the revocation descriptor (and knows which .onion it's for) to
broadcast updated 'echo' revocation descriptors of their own.
This could
be built to avoid the problems with static long-lived revocations.
[TODO: Expand in another document later]
4. Implementation
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.]
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.
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.
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.
5. Future Compatibility with Next Generation Hidden Services
Next generation Tor hidden services require a modified
revocation system because the hidden service master secret key is
better
protected, and does not need to live online on the hidden service
tor node.
The day-to-day operation of the service is carried out by a
pre-loaded set
of changing subordinate descriptor signing keys, which expire after
a set
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 a need
for a way to revoke descriptor signing keys and provide new ones,
but not to
permanently revoke trust in the hidden service.
Also, theft of descriptor signing keys should not allow an attacker to
revoke the master secret key.
The revocation permissions would looks something like the following.
(Blinded signing keys are equivalent to the master secret key for
revocation purposes because an attacker which obtains any blinded
signing
secret key can easily 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 new
descriptor signing key for that time-period.
3) Master secret key is the only one that can revoke master secret key.
5.1 Descriptor Signing Keys Revoking Themselves
[TODO: Finish later]
5.1 Master Secret Key Revoking and Replacing Descriptor Signing Keys
[TODO: Finish later]
5.2 Master Secret Key Revoking Itself
[TODO: Finish later]
