[tahoe-dev] [cap-talk] time-based authority

David-Sarah Hopwood david-sarah at jacaranda.org
Sat May 9 23:56:20 UTC 2009


[sorry if this is a duplicate]

David-Sarah Hopwood wrote:
> Raoul Duke wrote:
>> David-Sarah Hopwood wrote:
>>> Manual revocation, based on some user interface to a database that
>>> remembers all capabilities that have been granted (and metadata about
>>> the principal they were granted to, the context, etc.), would in most
>>> cases be far preferable.
>>
>> pardon me for stating the obvious follow on, but i will:
>>
>> and one could build the time expiry feature on top of that, if such
>> need really exists.
> 
> ... or more generally, any arbitrary revocation policy that can be
> expressed in the code of a revocation agent, or several such agents.
> 
> Caveat: if revocation always (or even sometimes) requires an explicit
> action, then it is desirable to minimize the impact of denial of service
> attacks against the revocation mechanism, since such attacks may be
> easier than more direct attacks against integrity. The way I would
> suggest to do this is not to automatically revoke an object on expiry
> of a timeout, but instead to *suspend* operations on the object on
> expiry of a timeout (effectively a lease), and have the revocation
> agent for the object periodically renew the lease before it is due
> to expire. Then, the object will recover from a DoS attack if and when
> its revocation agent recovers, and its clients will only have been delayed.

Note that for clients not to be able to observe a violation of the
system's message ordering constraints, there must be a way to selectively
delay messages from being received by given objects in a vat (or
equivalent).

> (If a particular client depends on timely service, then it should
> implement its own timeout.)
> 
> In an event-loop system, it may be sufficient to suspend objects only
> between turns, I think.

Here is a justification for that:

 - Some systems may support applying the side-effects of a turn atomically,
   only when and if the turn completes normally. In that case, it is
   sufficient to check just before the end of a turn whether any objects
   that were accessed by it have expired leases, and if so, abort the turn.

   (Note that client-server systems where each request to a server has
   atomic effects, are sufficiently like atomic event-loop systems for
   this argument to apply. In particular I think it could apply to Tahoe.)

 - Alternatively, there may be a timeout on the duration of a turn.
   For an attacker who can deny service to the revocation mechanism
   or agent, the worst-case time over which they can exploit an object
   after it should have been revoked is then its lease period, plus the
   turn timeout. This can be made much shorter than a revocation timeout
   would have to be, since turns are expected to be short.

-- 
David-Sarah Hopwood ⚥




More information about the tahoe-dev mailing list