Re: [tor-bugs] #15729 [Tor]: Proposal: Hidden Service Revocation

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#15729: Proposal: Hidden Service Revocation
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  Nathaniel
  Nathaniel              |     Status:  new
         Type:           |  Milestone:
  enhancement            |    Version:
     Priority:  normal   |   Keywords:  hidden, rendevous, descriptor,
    Component:  Tor      |  revocation, compromise
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by special):

 I like the concept. I agree with your arguments against implementing long-
 lived revocations, and I don't see any reason to make it more complicated.

 It might be worth mentioning that a client must not continue requesting
 descriptors from HSDir mirrors after receiving a valid revocation
 descriptor, so we remember to verify that behavior.

 There is a race between a real descriptor and revocation at every time-
 period rotation, but we can fix that. Revocation descriptors should be
 published some time before the time-period changes, and HSDirs must accept
 those. Currently, they accept descriptors up to REND_CACHE_MAX_SKEW
 (currently 24 hours, #13207) in the future.

 As a side effect, the revocation client would have to support publishing
 two sets of descriptors for different time periods simultaneously.

 There's another race any time the HSDir hash ring changes for the service.
 I don't think we can avoid that one, other than by making sure the
 revocation is published promptly after a new consensus.

 A malicious HSDir could ignore the revocation, impacting ~1/6 clients.
 This is detectable, only lasts one time-period, and I don't see any
 reasonable fix. That seems acceptable.

 > A revocation takes the form of a hidden service descriptor which
 provides no way to contact the hidden service (i.e. zero introductory
 points)

 This is a problem for clients that don't have the fix for #15601.

 > 5. Future Compatibility with Next Generation Hidden Services

 I'd like to see this figured out semi-promptly. We should avoid creating
 more work to finalize prop224 than we already have.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15729#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs