[cap-talk] delegatable-with-probable-cost capabilites

[David Hopwood]

ross mcginnis wrote:
> Hello all,
> 
> I have been thinking about non-delegatable password capablilities in
> person-to-person networks.  Because communication between people is
> not confined it is impossible (I think) to create a non-delegatable
> caps in these networks. A delegatable-with-probable-cost system can
> be used instead.
> 
> The basic idea of a delegatable-with-probable-cost is to let people
> freely delegate password capabilities to others, but if they do they
> face the risk of it costing/punishing them in some way.  Hence it
> dissuades them from delegating the capabilities.
> This is achieved by requiring the people who participate in the
> system to lodge a bond with the system.  The bond should be something
> that they would not like to lose but also something that others would
> like to gain.  Any capability that is created as delegatable-with-cost
> functions as a normal password capability as well as granting the
> holder the permission to anonymously collect the bond.  Thus anyone
> who delegates such a capability can potentially lose their bond.

I would like to respond more constructively to your post, but I don't
see any discussion of motivation (given that you don't claim it is
workable as an anti-spam scheme, and do not present any other example).

Delegation of authority is not undesirable -- quite the contrary.
It's particularly desirable to support it between processes, but it's
also desirable to support it between people. The only valuable
enforced restrictions on delegation are those that arise from restricting
communication channels (which incidentally, most non-capability
systems do a really bad job of). After the considerable amount of
discussion on this list about the topic, I still haven't seen anything
that would dissuade me of that.

[...]
> Please note: I'm not advocating non-delegatable or
> delegatable-with-probable-cost capabilities for use with high-security
> setups.  They cannot prevent conspiring proxy attacks.

Designers of security mechanisms don't determine what situations they
will be used in. There is no dichotomy between "low-security" and
"high-security" systems. Everybody uses *general-purpose* operating
systems, languages, and protocols; systems that are specialized for
high security uses would have no market to speak of (and would have
no impact on the immediate security crisis that affects all computer
systems). There is no point in designing for low security, because
people will still end up using those systems in sitations where a
compromise would have serious consequences (and because it's not
'cheaper' to design for low security; it actually ends up being more
complicated).

Sorry if this post sounds harsh; it is more an expression of frustration
with the direction of much of the recent discussion on this list in
general, than with this proposal specifically.

-- 
David Hopwood