145 lines
8.8 KiB
HTML
145 lines
8.8 KiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
<html lang="en">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|||
|
|
<style>
|
|||
|
|
body {
|
|||
|
|
max-width: 30em;
|
|||
|
|
margin-left: 2em;
|
|||
|
|
}
|
|||
|
|
p.center {text-align:center;}
|
|||
|
|
</style><title>Network Operating System</title>
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<p><a href="./index.html"> To Home page</a> </p>
|
|||
|
|
<h1>Network Operating System</h1>
|
|||
|
|
<p>The network should be stupid, and the applications smart as argued in the
|
|||
|
|
1984 paper <a href="http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt">End-to-End
|
|||
|
|
Arguments in System Design</a> by Reed, Saltzer, and Clark.</p>
|
|||
|
|
<p>The question then, is how do applications find each other and talk
|
|||
|
|
securely to each other?</p>
|
|||
|
|
<p>End-to-end as an ideal in network design has come under attack from
|
|||
|
|
network suppliers.</p>
|
|||
|
|
<p>to paraphrase Trotsky, the endpoints may not be interested in the middle,
|
|||
|
|
but the middle is interested in the endpoints.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<h2>Solution</h2>
|
|||
|
|
<p>Build a crypto currency with the equivalent of namecoin built in.</
|
|||
|
|
<p>Link in the </p>
|
|||
|
|
<p><br/>
|
|||
|
|
</p>
|
|||
|
|
<p><br/>
|
|||
|
|
</p>
|
|||
|
|
<p>Naming system follows Zooko’s triangle. </p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> Your browser bookmark list, and your various contacts lists <i>almost</i>
|
|||
|
|
support Zooko’s triangle, and <i>almost</i> have Zooko like behavior, but
|
|||
|
|
have various small subtle deviations in their behavior that make them not
|
|||
|
|
quite suitable.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p>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. .</p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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 <a href="./duck_typing.html">duck
|
|||
|
|
typing</a> – 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 <a href="./duck_typing.html">duck type</a>
|
|||
|
|
error. Remember, end users, not programmers, will be making
|
|||
|
|
connections, thus the flexibility of <a href="./duck_typing.html">duck
|
|||
|
|
typing</a>, which causes much grief for programmers, would cause
|
|||
|
|
intolerable grief for end users. </p>
|
|||
|
|
<p>Since we automatically have end to end encryption, we can transmit
|
|||
|
|
capabilities, including capabilities with monetary value. </p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>Everything in the system is an object, in the sense of uniting data and
|
|||
|
|
code, and exposing some interfaces </p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p>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.<br/>
|
|||
|
|
</p>
|
|||
|
|
<p> </p>
|
|||
|
|
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
|||
|
|
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
|||
|
|
Commons
|
|||
|
|
Attribution-Share Alike 3.0 License</a></p>
|
|||
|
|
</body>
|
|||
|
|
</html>
|