[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[James A. Donald]

 > > > What Horton shows is that an effective mechanism
 > > > to determine who did what can be added to
 > > > object/capability systems...

James A. Donald
 >> Had I been responding to such a criticism, I would
 >> have found it sufficient to say that one can track
 >> who is using a capability, and who was issued the
 >> capability.

Jed Donnelley
 > Exactly.  Horton does simply that.  If you have an
 > alternative, simpler approach, please describe it.

Think I did, with a particular concrete example.  You
did not seem terribly interested.

James A. Donald:
 > > Horton seems to me the approach of a mathematician,
 > > rather than an engineer.  Mathematicians infamously
 > > "solve" problems by "reducing" them to an already
 > > solved problem, which "reduction" tends to make the
 > > problem much bigger, rather than much smaller.

Jed Donnelley
 > Uh - but the problem is solved.  Before it wasn't.
 > That seems to me a huge contribution.

Solved in the sense that is important to mathematicians.
I don't think that Horton is a solution that should be
very interesting to engineers.

 > Now if you wish to suggest a better engineered
 > solution to the problem

By selecting a particular case, I had a well defined
problem.  For that well defined problem, the problem did
not seem very hard, and the solution (OTR + Rob Meijer's
mailkey) considerably simpler and lower overhead than
Horton.

 > - fire away.

I did, in the post titled mailkey: "transfer of
accountability. Is this broken ?? should I start from
scratch/horton ?", and again in the June 2nd post titled
"What Horton cannot do? (Was: mailkey: transfer of
accountability...)"

Repeating from my June 2nd post:
: :	Let us consider the application of this to
: :	some real world cases.
: :
: :	Let us suppose we manage to get in place an
: :	email system where all email is authenticated
: :	by a public key, but not signed by a public
: :	key - that is to say, the recipient knows
: :	what key it came from but cannot prove this
: :	to others.  We assume entities are ultimately
: :	identified by their key, not by a "true name"
: :	that is somehow bound to the key.
: :
: :	Naturally spammers promptly issue themselves
: :	several billion keys - which is roughly what
: :	has happened with the various initiatives
: :	such as DKIM, where spammers were the
: :	enthusiastic early adopters.
: :
: :	We therefore adopts something like Rob
: :	Meijer's proposal.  Each of us generates
: :	large numbers of authorities to contact
: :	himself, and dispenses them throughout his
: :	social circle, discarding the ones that leak
: :	to spammers.  These authorities are just
: :	large random numbers in a database, no
: :	encryption involved. Anyone in my social
: :	circle can give one of these authorities to
: :	contact me to anyone in his social circle.
: :
: :	In this situation, what does Horton buy us
: :	that Rob Meijer's proposal, plus
: :	authentication does not buy us?

But you do not seem to regard concrete and particular
cases as meaningful - as illustrating general solutions.
So here is the same solution in general terms.

Assume a system such as Zooko's triangle, where all
entities have public private key pairs, a but many key
pairs are unknown, and we do not in general know if the
possessor of a certain key pair should be exercising a
capability.   Adversaries have such key pairs as much as
allies, but allied key pairs are known, while
adversarial key pairs are likely to be unknown.

All capabilities are shared secrets, that are issued to
particular identifiable individuals.

A Zooko identity is a smart browser bookmark as in the
petname tool, or a smart buddy link, as in OTR IM.  A
capability is an unguessable URL.

In Horton, each capability is issued to one, and only
one, entity, and should be exercised only by that
entity.

Alternatively, we can pass around capabilities, but
since we know who is exercising them this is not too
bad.   Any entity exercising a capability that we do not
want widely shared, exercises after first logging on
using his Zooko key. If a capability issued to Alice
turns up in the hands of unknown bad people doing bad
things, then Alice has been bad in sharing her
capabilities unwisely, and that is Alice's fault.  If a
capability issued to Alice turns up in the hands of Bob,
a known person who Alice could reasonably have shared it
with, but Bob does bad things, then that is Bob's fault.

James A. Donald:
 >> As a demonstration that capabilities can support
 >> identities, Horton doubtless works.

Jed Donnelley
 > To me it isn't "doubtless", but it does indeed seem to
 > work.  A somewhat surprising result from my
 > perspective given the "bearer right" aspect of
 > capabilities.  When a key opens a lock, do you know
 > "who" was responsible for that opening of the lock by
 > that key?  Generally not.

"who" contains too many meanings.  Identity is not a
clear well defined concept with clear well defined
meanings and definite unambiguous solutions.  If each
key is unique, as is typically the case with electronic
keys used in office security systems, then the owner of
a key will be disinclined to share it, whereupon knowing
what key opened the lock is in fact sufficient
information.  Of course, there is lots of stuff that can
only be done, or is simplest to do, by passing out keys,
by delegating capabilities.

The problem is not well defined except by reference to a
real or hypothetical identity system, and real resources
that need protecting.  The real problem is too amorphous
for us to casually assume that abstractions of it have
clear meaning.

OTR plus Rob Meijer's mailkey works by requiring two
keys to access the capability, one of which the owner is
likely to be disinclined to share, and one of which the
owner will be inclined to share - so when the door is
opened, we know "who" opened it - the key that is
unlikely to be shared - and who allowed him to open it -
the key that is likely to be shared.  If Alice should
have allowed Bob to enter the office, the office manager
presumably knows Bob, and will grill him if something
bad happens.  If Alice is allowing strangers into the
office, the office manager will grill Alice.

James A. Donald:
 >> As a proposal for an actually useful system, I doubt
 >> that it works.

Jed Donnelley
 > I agree that in it's current form(s) Horton is not
 > part of a useful system solving important problems.
 >
 > Still, I've developed capability based systems (e.g.
 > the NLTSS system that ran production scientific
 > computing at Lawrence Livermore National Laboratory
 > for over 10 years:
 >
 > http://en.wikipedia.org/wiki/NLTSS
 >
 > ) that I believe could have benefited by a mechanism
 > along the lines of Horton.  It was one of the
 > implementations that was criticized in this document:
 >
 > TRADITIONAL CAPABILITY-BASED SYSTEMS: AN ANALYSIS OF
 > THEIR ABILITY TO MEET THE TRUSTED COMPUTER SECURITY
 > EVALUATION CRITERIA
 > http://www.webstart.com/jed/papers/P-1935/
 >
 > - along with all other capability systems.

That criticizes "traditional" capability systems.  But
all "traditional" systems - including the systems we are
using right now - are alarmingly insecure.  That does
not seem to me like a criticism of capability systems
that urgently needs answering.

 > The problem that we (speaking generally for cap-talk)
 > are trying to address is that of POLA. Namely,
 > replacing the current approach of running programs
 > where the programs run as a "user" with all the user's
 > permissions (often here referred to as "ambient
 > authority" - authority according to who the program is
 > running) with a system in which programs can be given
 > just the permissions that are needed to provide
 > whatever service is needed of them.
 >
 > This is a very important practical problem.  Ever had
 > a system of yours become infected by a virus? Ever
 > decide not to run a program (e.g. that executable
 > Christmas card or perhaps a computer game available on
 > the Internet) because you were afraid of what it might
 > do to your system if you ran it with all your
 > authority?

You are preaching the choir.  Horton is not POLA.
Everyone on this list agrees with POLA and capabilities.
Horton is an attempt to address identity through
capabilities.  I don't think it is a good fit for most
real world cases.

Identity is the omniproblem of present day networks,
from which all problems arise, and to which all proposed
solutions return.  Thus identity solutions tend to be
ill defined, or built around artificial and unreal
threat scenarios.  Whenever anyone has a hammer, he can
be relied upon to announce that identity is a nail.

James A. Donald:
 >> When dealing with abstractions, it is easy to get
 >> lost and not notice.

Jed Donnelley
 > There is nothing abstract about using capabilities for
 > POLA to deal with the threat from viruses,

Horton, however, does not directly address anything so
concrete as the threat from viruses.

James A. Donald:
 >> It seemed to me that Horton is lost and does not know
 >> it.

Jed Donnelley
 > I wish I understood why you feel that way.

I have explained, and you snipped my explanation without
making any relevant response.  I have explained again in
different words, and I expect you will snip that
explanation also and make irrelevant response or no
response.

I am sick of retyping.  If you really wish to
understand, you should reread.

James A. Donald:
 > > Building identities on top of capabilities is rather
 > > like writing a bit wise addition operator in lisp,
 > > to operate on bit patterns represented as sets.

Jed Donnelley
 > Uh, except that lisp has a working addition operator.

If it did not have one, it would be an exceedingly bad
idea to write it in lisp, or to represent integers by
sets.

 > Capabilities do not have a working identity mechanism.
 > Are you suggesting building such a mechanism into
 > capabilities somehow?

And I have given a concrete example.

 > What we are seeking is:
 >
 > 1.  Practical POLA control of permissions.  We believe
 > the most effective way to achieve this value is
 > through communicable tokens of permission (objects)
 > that we refer to as "capabilities" or
 > object/capabilities.
 >
 > and
 >
 > 2.  Identification of responsibility for permitted
 > actions.
 >
 > Any way of achieving the above is fair game.  How do
 > you believe the above should be achieved James?

I have explained three times so far.  Perhaps you should
re-read, for I doubt that me retyping is going to have
any results different from the first three explanations.