The network should be stupid, and the applications smart as argued in the 1984 paper End-to-End Arguments in System Design by Reed, Saltzer, and Clark.
The question then, is how do applications find each other and talk securely to each other?
End-to-end as an ideal in network design has come under attack from network suppliers.
to paraphrase Trotsky, the endpoints may not be interested in the middle, but the middle is interested in the endpoints.
Providing optimized service, providing degraded service (for example to collect rents to restore service to normal levels), and surveillance are all reasons for the network to take an active interest in what its endpoints are doing.
The solution is end to end encryption at the packet level, encryption on top of udp, with reliable encrypted transport on top of unreliable encrypted transport rather than SSL on top of TCP – but, as experience has proven, end to end encryption does not work with unique true names, which is what DNS was designed to support. Need Zooko’s triangle in place of DNS, rather than on top of DNS, so that you find the network address of an entity from the hash of the rule that its public key satisfies.
In other words, for the end points to enforce the end to end ideal a whole new infrastructure on top of UDP and in place of TCP, DNS, and CAs is needed.
Build a crypto currency with the equivalent of namecoin built in.Link in the
Naming system follows Zooko’s triangle.
Because humans cannot themselves perform cryptographic operations, nor remember public keys as names of entities, the user interface becomes part of the security problem. It is typically the unsecured part of a secured channel, the weak link in the chain.
Thus a security proposal needs to be described with a description centered on its user interface and perceived behavior. The security behavior should reflect the user interface – it should behave as the user expects.
Many of our security problems arise because the email interface is inconsistent with its actual security properties: An email that appears to come from Bank Alice does not necessarily come from Bank Alice.
Thus general security requires a secure name system, Zooko’s triangle, which requires not just a bunch of cryptographic algorithms, but a bunch of tools for managing and sharing information about names – requires a whole lot of secure user interface.
Your browser bookmark list, and your various contacts lists almost support Zooko’s triangle, and almost have Zooko like behavior, but have various small subtle deviations in their behavior that make them not quite suitable.
This is in part because they were built without concern for security, and in part because they are built on top of a system that is wildly different from Zooko’s triangle.
In a system based on Zooko’s triangle, you would not have DNS, for DNS exists to render true names for network addresses humanly memorable, and in Zooko’s triangle, true names for network addresses are not humanly memorable. Thus building a Zooko system on top of the existing system turns out to be problematic, even though in practice DNS urls are seldom all that humanly memorable, so that actual usage and actual user interfaces have become Zooko like, it insecurely maps non unique human memorable names to unique, non human memorable, insecure names. A secure naming system would securely map non unique human memorable names to unique non human memorable cryptographically secure names.
DNS requires a center, since the supply of human memorable true names is limited, and therefore true names have to have a price. This center leads to no end of security problems. A system in which true names are or contain hashes of rules identifying public key chains can be centerless, and therefore end to end.
Globally unique names for mutable items are a public key plus some network hinting non human readable information, plus non human readable distinguishing information for all the many mutable items associated with a single public key. Immutable items are a hash plus some network hinting non human readable information. .
These get converted into a network address and shared secrets. The conversion process should support NAT penetration. The network address and shared secrets constitute a connection, which may then, for some objects, get converted into a local copy of the object.
At this point protocol negotiation occurs, in which the protocol is identified absolutely, and in a duck type sense. (You don’t want to make a connection that is then going to crash for failure of duck typing – you want such failure to occur immediately, where it will give a version error, rather than in the middle of the interaction, where it will give an obscure duck type error. Remember, end users, not programmers, will be making connections, thus the flexibility of duck typing, which causes much grief for programmers, would cause intolerable grief for end users.
Since we automatically have end to end encryption, we can transmit capabilities, including capabilities with monetary value.
Capabilities with monetary value are a low level concept, a software primitive that all applications can easily and routinely use. A bank account is a swiss numbered account, and all you need to “open” an account is to invent a public key, private key pair.
Everything in the system is an object, in the sense of uniting data and code, and exposing some interfaces
The code that implements those interfaces is downloaded with the data - but, as with Caja, it is limited by the capability discipline so that it cannot take over your computer. It can only do stuff through capabilities you pass in, or that it brings with it. It does not have access to the rest of your computer, except through such capabilities as you pass in, as in Caja.
Every object can be inspected by other objects, in that other objects can see its methods and the argument types that its methods require, as in the Go language’s duck typing.
With some objects, you can interact with them over the network, passing them object identifiers as arguments, with other objects, you download a local copy, and with some objects, you can do either one and it is optimized on the fly. The distinction is translucent, but not transparent.
The most trivial objects, and one of the most common arguments, is an immutable string or number, which can be represented by its hash, but for small strings, is usually identified by the string itself. However, if what you are passing is, for example, access to a routine that makes available resources on another computer, a high level object, duck typing means that it is known to be a high level object, not a string that the program applies ad hoc code to to turn into a high level object. If it is an object of the wrong type, duck typing will generate a relatively meaningful error message.
Objects interact by message, rather than by call – every object has a
message pump. If you want to have call semantics, have to
laboriously put in Send message, handle reply.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License