Network addresses shall be opaque blobs, which may in practice consist of
an IP4 address plus some variable precision additional subnetwork address,
or may consist of an IP6 address some variable precision additional
subnetwork address, or some unknown future implementation for some non
standard network.. Only the lowest level software knows or cares. To
everything above, a network address is an opaque blog of unknown length
and unknown internal format, which is by default non human readable and
non human writeable, though some subtypes may be human readable and
writeable.
There is a member function which may yield a derived class that is human
readable and writeable, but likely yields the null pointer. The
additional subnetwork information is used to handle the now common case
that there are many entities on a single machine.
Which is to say, network addresses are implemented as a set of classes whose internal details are as far as possible hidden, derived from an interface base class, and all other software calls the methods of the interface base class.
Similarly for public keys, and indeed everything else. Exposing the internal structure of network addresses and port numbers and so on and so forth to everything was a huge mistake.
The base classes of these heterogenous objects with common behaviors are
of course, abstract classes. Our networking system shall be built on
top of abstract classes, unlike the existing system where class internals
are exposed.
Given a network address, a member of our opaque classes, be able to send unreliable messages in the clear. UDP equivalent, but as yet no TCP equivalent. At this point, we make absolutely no attempt to deal with NAT barriers.
Client knows server public key and server network address.
Client and server construct strong shared secret despite the possible
presence of an active man in the middle adversary. To deal with
replay attacks, establish shared global time and shared probabilistic
offset from that time. (Server and client agree to disagree on global
time, but know how big a disagreement they have. Everyone tries
to have their shared global cryptographic time to be the median
offset)
Client knows server network address and server public key. Client and server know username and weak password or hash thereof. Client and server construct strong shared secret despite the possible presence of an active man in the middle adversary.
Client knows server network address but does not know server public key, or anything that would allow it to reliably identify the server public key. Client and server know username and weak password or hash thereof. Client and server construct strong shared secret despite the possible presence of an active man in the middle adversary.
Unite all the above code as derived from a single abstract base class, which caches the connection between client and server, regenerates a shared secret as needed.
We define the class “connection”. A connection is a member of a class containing shared secret and network address information. We have not yet, however, got to a concept replacing port number, or even got anywhere near being able to build user interface. We have however, placed what we need for encryption where it belongs, at close to the most foundational level. Encryption first, port number equivalent and TCP equivalent on top of encryption. Then we get to UI later, and then we will get to how to know these public keys, or hashes of rules identifying public keys.
The encrypted connection, and, finally ports. The encrypted connection is a connection with encryption information. Packets arrive with position information as to the order in which they were sent, though not all packets arrive, and not in original order and some are garbled. Packets are authenticated then decrypted and assigned to their appropriate port, so when they get to the port they are authentic, correct, and have known positions within the port stream and connection stream, though not all make it to the port, and not in order.
Ports are an encrypted connection plus protocol agreement information. For every connection, there are usually two ports, one to manage the creation and destruction of ports and the connection, and at least one to actually transport useful information.
A port references an encrypted connection, probabilistic information about the current state of information exchange, and a protocol description.
Thus, the very first protocol is a protocol to negotiate new ports and thus new protocols, and to shut down this connection.
This could potentially create additional round trips, thus we have have a general rule for collapsing round trips, "Assuming you agree to the proposed protocol, here is first packet of that protocol." If server does not agree, then client adjusts its assumptions about server state.
Each side transmits on its best guess about the state of the other, but can back up to an earlier point in the state machine if such provisional transmissions are revealed to be in error.
In the present tcp implementation, the client is a state machine, and the server is a state machine, and they try to tend to corresponding states. Thus the client state embodies knowledge about the server state. I suggest that instead the client maintains a list of possible server states, and as events happen, updates the weightings of each guess as to server state.
The client also needs to model server guesses about client state, and the server needs to model client guesses about client state, an estimate about an estimate.
Server ids contain a link to a list of protocols they accept, signed by an authority responsible for those protocols. Protocols are identified by stream of bytes, in which zero or bytes have their high bit set, the stream being terminated by a byte with the high bit cleared. Lists of protocols are maintained by the system responsible for the list of server ids, with new lists only being added by a human decision at the distinguished proposer.
These lists only identify protocols capable of setting up a connection. When a connection is made, the client offers a list of subprotocols that it wants, and the server accepts the first one in the list that it recognizes and wants to handle. We will have no central authority for such subprotocol lists. Anyone can roll there own, and in the event that there come to be a lot of them, the implementer just chooses an identifier long enough and random enough that the risk of collision is small.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License
And, in any case, are a proposal for software that can be used to massively copy copyrighted material.