xaviervia
commented
11 years ago A quick draft:
The highlighted features of JSSTP should be:
- Provide not just security for the messages in the communication, but also a certain degree of anonimity for the connecting party.
- Provide end-to-end message encryption, so that messages do not get decrypted in the intermediate servers.
The part about anonimity refers to dealing with Transport Protocols. Unfortunately, JSTP has to be carried in a server-client architecture Transport Protocol in which a connection has to be established prior to any JSTP Dispatch. Clients and servers can in the Transport Protocols be usually identified by their IP addresses and domain names. There is no clear-cut solution for this yet, though some may appear in the future. JSSTP should be able to fully profit for improvements in anonimity.
The part about end-to-end implies that asymmetric encryption handshakes should be able to be performed by parties behind gateways. The gateway must not be able to decrypt the actual message. This means also that JSSTP should probably implement a wrapping mechanism so that Dispatches can be triggered for a special Method and a bland token in the Resource to be captured by the parties to which is destined.
Since JSSTP encryption will be end-to-end, TLS is not useful at all.
Encrypted JSSTP Dispatches should be able to circulate over a network of untrusted Engines before reaching its destination.
JSSTP should also provide a new way to validate public keys. Current browser implementation of TLS is not accessible and this has hindered substantially the end-user average security on the Internet. Public key validation authorities should be able to provide the service for free, since an authority is trivial to set up and domain validation can be performed in a completely automated fashion, with methods such as those used by Google Analytics. Security for end users can be tolerably warranted if the public key of several authorities if shipped with the Engines implementation and furthermore if an automatic authority validation and authority validity API is set up. And if it is trivially easy for the power user to set up extra authorities.
The Authority Validity API can be set up with a resource-sharing market protocol in place. It may look something like this:
- Some aspiring authority asks for validation status to an existing, trusted authority, and following the protocol, is granted such a validation.
- The user accepts to test the new authority by using its data as authoritative information for public keys, but every time a new public key appears, it checks it with the old authority for extra safety.
- If no error is found, the user agent rates the new authority as safe.
Of course, this would not allow for the new authority to register public keys on its own, but once its trusted status is outstanding it can join a network of trusted authorities.
The handshake
The handshake should be a typical public key handshake: the client send its public key, the server returns its own public key encrypted using the provided public key, the client then creates a private key that sends to the server using the server's public key, and further communication is performed using the private key with the symmetric algorithm.
The fun stuff is that there may not be a specific server but another client bound to a remote engine in which the communication is started. This is the case in a chat server. In this case, public key encryption allows for the handshake to occur through the remote engine. The clients may bind themselves to the other party's public key endpoint. I imagine something along the lines of "SECURE [public key]". Many a sniffer may bind itself to another person's public key using this scheme, but since they cannot decrypt the message, its mostly pointless. Of course, this relies heavily in the strength of asymmetric encryption.
Thus, JSSTP would probably be needing public key authority services and kickstart the computing-resources market. Also, an implementation similar to that described above would make it public keys the de-facto universal identifier of application instances.
JSTP should provide a secure alternative. This cannot be simply achieved by running the JSTP Transport Protocol over TLS because of the distributed nature of JSTP which has each JSTP Engine working as a Proxy in many occasions. What is needed is a JSTP level encryption solution with asymmetric encryption and that allows Engines to identify remote resources (sometimes several steps away along a network).