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 physical communication of suitable quality 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 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.