[tahoe-dev] time-based authority

[David-Sarah Hopwood]

[cc:d to cap-talk from tahoe-dev]

Troy Benjegerdes wrote:
> I was reading the 'hack tahoe' page ( http://hacktahoe.org/csrf.html ),
> and I started wondering if or how time-based capabilities could be
> introduced. I think this is particularly important longer-term, as the
> capability model based around unguessable/unforgeable URL's is great
> from the mathematics and crypto perspective, but kinda flawed in the way
> humans work.

Personally I think that automatic timed revocation is actually much more
deeply flawed, with respect to how humans work, than untimed capabilities
are often perceived to be.

The main issue is that there is no good choice for a timeout period:

 - if the period is too short, then the human management overhead of
   renewing capabilities will be unreasonably high (renewal cannot be
   automatic since then compromised capabilities would also be renewed);
   and the reliability of the system will suffer as a result of capabilities
   expiring too early.

 - if it is too long, then there is negligable security benefit because
   an attacker will have plenty of time to obtain anything they might
   want from exploiting a compromised capability (and possibly obtain
   other authorities from it derived from capabilities that will expire
   later, if at all).

Unfortunately, there is usually no range inbetween. In fact there is
typically a wide range of periods that are *both* too short and too long --
that is, the management overhead is too high and the security benefit is
also negligable. To be more concrete, I think that any period less than
a few days is too short for most authorities, and anything more than a
few hours is too long.

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.

-- 
David-Sarah Hopwood ⚥