[cap-talk] Articulating Reliance Assumptions (was: Capability levels - transparent network extension, no encryption)

[Jed at Webstart]

Overview:

Regarding central points of failure in capability distribution mechanisms,
I believe we reached a consensus when Mark dropped his "necessarily"
claim at the end of the message (after reviewing what he refers to as
the "guarded corridors" scenario and that I see in a somewhat more
general context - interested readers can take away their own opinions).

I agree that for network capability communication using cryptography
is generally preferred to using hardware means to protect network
addresses - though I believe both can be helpful and complimentary
to some extent in terms of "protection in depth".

There is also some discussion below about "transparency".  I'm not
quite sure what Mark is referring to when he says:

>These scenarios <apparently referring to:
http://www.erights.org/elib/capability/dist-confine.html
> > are non-transparently different from simple object-capability confinement
>since the need for these choices must be visible.

To me the scenario at the above Web site is essentially (fully?)
the DCCS mechanism.  I believe the DCCS mechanism to be
fully transparent.  Consequently I think I either don't understand
or don't agree with the above statement about "non-transparently".
Except for that I believe the message below is a simple recording
of agreement, but I'll leave it in it's sequential flow:

At 01:09 PM 8/20/2006, Mark S. Miller wrote:
>Jed at Webstart wrote:
> > ...tying this back to the source, this is the quote from your
> > thesis that I was concerned with:
> > _______________________________________________________________
> > "11.5 The Limits of Decentralized Access Control
> >
> > This dissertation mentions three forms of capability system:
> > operating systems like DVH,
> > programming languages like the non-distributed subset of E, and
> > cryptographic capability
> > protocols like Pluribus. The object-capability model we have
> > presented applies only to the
> > first two: operating systems and programming languages. Our model
> > implicitly assumes a
> > mutually relied upon platform, which is therefore a central point of
> > failure. In the absence
> > of this assumption, we are left only with cryptographic enforcement
> > mechanisms. Cryptog-
> > raphy by itself can only enforce weaker access control properties. In
> > exchange, cryptography
> > enables us to build systems with no central points of failure."
> > _________________________________________________________________
> >
> > ... You say "Our model
> > implicitly assumes a mutually relied upon platform [e.g. as you seem
> > to suggest above the two CCS systems that mutually rely on each
> > other], which is therefore a central point of failure."  Why is it
> > that a "mutually relied upon platform" implies a single point of
> > failure?
>
>It follows from the meanings of "relied upon", "central point of 
>failure", and
>"platform".
>
>First, I should double check that you find my usage of "central point of
>failure" acceptable:
>
>  From section 5.2:
># Given a set of objects, anything within the reliance sets of all of them is
># a central point of failure for that set. A platform is a central point of
># failure for the set of all possible programs running on that platform.

That sounds fine to me.

>In other words, if Alice and Bob both rely on Carol, than Carol is a central
>point of failure for the set {Alice, Bob}. Everything in the set is 
>vulnerable
>to Carol's misbehavior. Even if Alice and Bob are correct, if Carol
>misbehaves, then they may too.
>
>Let's say that Alice and Albert are objects hosted on CCS platform 
>A, and that
>Bob and Betty are objects hosted on CCS platform B. Alice and Albert
>necessarily rely on platform A and Bob and Betty necessarily rely on platform
>B. If A relies on B, then B is a central point of failure for the set of
>everything we're here talking about.

Yep.

>OTOH, if A and B are mutually non reliant, but Alice relies on Bob, 
>then Alice
>also relies on B, but Albert does not. Mutual reliance among *platforms*
>creates central points of failures and should be avoided. However, among
>object running on mutually defensive platforms, it is normal for
>application-level decisions of some of these objects to rely on some of these
>other object, and thereby to rely on their platforms. This is the necessary
>price for many patterns of cooperation.

Exactly.  We're on the same page so far.

>The distributed confinement examples
>of 11.5.1 and http://www.erights.org/elib/capability/dist-confine.html both
>involve application-level choices to rely on other platforms.

And doesn't that example (machine A and machine B with a DCCS
mechanism between them - A knows that only B is on the channel and
visa versa) form a distributed capability system with no single point
of failure?  I gave an example previously with A, B, and C all communicating
directly over point to point channels.  I think the principle is the same.
Alice only makes a capability available to Bob through normal
capability communication.   The fact that Alice's capability is
stored by a network server on machine A for access by machine B
is invisible to Alice and to Bob.

>These scenarios
>are non-transparently different from simple object-capability confinement
>since the need for these choices must be visible.

Why do you say so?  I believe the scenario with the DCCS mechanism
is completely transparent - at least at the application level (Alice and
Bob).  Of course for Bob to be confined Alice must depend on B, just
as you've indicated that since Alice chooses to depend on Bob then
Alice thereby chooses to depend on B.

>How does a non-crypto system assure the authenticity of network addresses? In
>a DCCS system, how do we know that other machines haven't been plugged in to
>the wires in question?

We can have one or more wires coming into our building.  We don't care
what's outside the building - that could be anywhere with anything on it
(we can protect electrical, etc.).  We assume that whoever is at the other
end plays the DCCS protocol.  If they do then they can get access to the
capabilities shared through the DCCS mechanism.  If they don't then it's
hard luck for them, they just get fewer (perhaps none) capabilities.

I admit that from a practical viewpoint this is a bit of a strained example
(e.g. vs. using encryption on a more general network).  I'm trying to
pursue the principle here, e.g. regarding:

>If the answer is "we guard physical entry into the building which houses all
>the wires and machines", then the building and its guards are a central point
>of failure. If the answer is instead "we assume that no one will build a NIC
>card that will lie about its MAC address," then each NIC card is a central
>point of failure for the entire system.

I believe in the above scenario (wire coming into building from remote)
there is no single point of failure.  A knows that it's talking to B over the
channel and only B.  No guard is needed.  No NIC failure can break the
integrity of the system.  You seem to agree later when you say:

>Here's one I can imagine: The room housing platform A is guarded by 
>A's owner,
>and likewise with B and C. The wire between A and B runs through corridor AB
>and is guarded by both A's owner and B's owner. Likewise with AC and BC. The
>building as a whole has no guards -- we only have guards on these individual
>rooms and corridors. If A is bad, B and C can still authenticate and
>communicate securely. This scenario does not use crypto and has no central
>points of failure.

That was exactly my point and example.

>...
 From my perspective the integrity of the network addresses is a technical
problem to be solved - e.g. by hardware means as I described above or
by software means (e.g. cryptography).  Both can work.  I think in the
case of a network like the Internet the cryptographic protection is the
one to use.

Notice that with a DCCS mechanism (as described in the paper with
ACLs) a failure of the network address mechanism means that
B may be able to get access to capabilities that were distributed
to C, but there is still no way for any remote system to get access
to capabilities that weren't shared over the network.

>...
>So I think I agree that you can have both in theory. However, I don't think
>such possibilities are very practical. If you want a decentralized system of
>virtual secure wires, just use crypto. Once you do, these can be multiplexed,
>tunneled, and made to span great distances. Without crypto, they can't.

I agree cryptography is more practical for large networks like the Internet,
though even there some amount of protection in depth is possible.  E.g.
having an Internet gateway router check incoming packets to insure that
they don't appear to be from IP addresses that should be internal to
a LAN.

> > From my perspective a transparent network extension of a CCS such as
> > the DCCS could be implemented without cryptography (as was done in
> > the DCCS paper) or with cryptography (e.g. as described in the
> > Managing Domains paper - though in a strictly network context) and
> > the fault tolerance would be the same.  You seem to suggest that such
> > implementations must necessarily be different regarding single points
> > of failure.
>
>For the above reason. But having walked through the above "guarded corridors"
>scenario, I drop the "necessarily" claim.

There we go.

I now think we have a common (shared, not vulgar ;-) understanding of what's
needed and available at the level of protecting network addresses and likely
at the next level of protecting capabilities (e.g. as per the Managing Domains
paper:

http://www.webstart.com/jed/papers/Managing-Domains/

).

For me the biggest issue with distributed capability communication
is at the data formatting level.  Since this takes me back to the discussion
that I was having with David Hopwood, I'll leave this thread with this
message and pick that former thread up as appropriate.

--Jed http://www.webstart.com/jed/