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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev