New issues arise with three sites.
In an earlier
scenario we had two distributors A and B doing their thing.
A linked sites x and y while B linked sites y and z.
If we assume that there is efficient physical communication between sites x and z we
may want to allow direct communication between x and z.
This may:
- Reduce transmission cost
- Reduce latency
- Be less vulnerable to communications failure
- Leave x and z connected upon failure of y.
To this end we suppose that A and B merge interests and cooperate.
Now when a forwarder Z in y gets a message destined for
z and that message holds a reference to something at x, then the forwarder
can recognize that reference as actually a sibling in the newly extended
family. Unless y has already introduced x and z it does so. This may be
done by sending the public Diffie-Hellman key of either to the other. This
provides x and z with a shared secret for either authentication or encryption.
y does not share that secret. The object at x is identified by the index
that the link from y to x would use to identify the object, along with
a site code. This case is insecure as it stands. Site x has no reason to
believe a signal from z claiming access to the object at x since site z
could have fabricated such a signal without help from site y. The forwarder
Z at y must include an authenticated signal to x embedded in the signal
to z. That signal says to x: "grant to site z access to the object number
13 as known over the x-y link". Site z will forward the embedded message
to site x as it claims access to the object there.
There are several interesting points about this protocol:
- Referential integrity does not require secrecy (link encryption)
- An application distributed over a subset of the network is vulnerable to
corruption only at the sites where it has chosen to run.
- Components of the application that are even less distributed are even less
vulnerable.
Sometimes, counter to our assumption, the communications infrastructure
does not support connections (links) between arbitrary sites well. The
infrastructure may be physical links. Still iterated forwarders are a poor
solution. It is possible to build a signal forwarding service that provides
the effect of arbitrary links. This service may be provided outside the
confines of the capability system. It has the curious advantage that subsequent
subversion of an intermediary site can deny service but not spoof or spy
on an encrypted link that it hosts. These questions rapidly become questions
of network design which is not our purpose here.
Problems?
A strange almost mystical problem nags. When a site receives the DH key
to a previously unknown site it may come with a built in man-in-the-middle.
If site A sends site B's DH key to site C, and C has already established
communications with B then all is well. If the DH key is the only way that
sites designate sites to each other then the man-in-the-middle must build
his reputation just as any other site. An application must use means outside
the the scope of communications protocols to decide which sites are secure
enough for its purposes. If some site naming convention other than its
public key were used, then establishing a site's public key would lead
to the well known public key infrastructure problems. Those problems evaporate
when the public key is the name. Only the problems of reputations remain.