--- sn_wot.txt.04 Tue Mar 23 12:34:53 2004 +++ sn_wot.txt Tue Mar 23 18:02:18 2004 @@ -1,11 +1,12 @@ An idea for distributed secure/reliable social network -version 4 +version 5 by Vasil Kolev, vasil(at)ludost(dot)net -1) Todo - Appendix A and B, email and native transport methods + - Check appendix B for needed clarifications + - Possible attacks against the native transport 0) Disclaimer (all rights reserved, blah blah) @@ -123,14 +124,18 @@ it gives a lot of ways to route around all kinds of firewalls and censors. The only requirement of such system is to have a way to deliver the requests reliably enough, the authenticity and confidentiality is guaranteed -by the core system. +by the core system. + There is nothing that binds a client to use only one method for transport. +It's possible that some clients can act as gateways between different +transports, or just use them to get some redundancy. 4) Principle of operation 4.0) Prerequisite Every request here, unless stated otherwise, is signed _and_ encrypted. -Every received request is acknowledged by the receiver. +Every received request is acknowledged by the receiver, and has unique id, +consisting of user's key id, the current time, and a random string. 4.1) Joining the network @@ -297,7 +302,9 @@ traced through the signatures of your friends. Also everything you send is provable to be sent by you, by the signature of the request, because as a rule, a request can't be accepted if it hasn't got a -valid signature. +valid signature. Communities can anonymize content, but then there +can't be any guarantee that it came from someone within the system, +and could be treated as spam. Every normal participant in the system will be able to keep track of events, like new keys, changes of FL, changes in profiles (that he has access to), etc. This exists in current such networks, too, but here @@ -319,3 +326,119 @@ database, the synchronization of the servers (one server will be a single point of failure, and the database will have trouble being split, because you won't be able to verify all the signatures). + + + + Appendix A. Email transport layer + + + This is the simplest way to transport data from one client to another. +It uses files attached to messages, and receives requests through email. +Every request will be a separate encrypted and signed file. + Every user can decide for him/herself about forwarding requests for +other people, about forwarding 'broadcast' requests (such as key revocation). +Disabling broadcast propagation might be dangerous, if someone has only +one friend/peer, and the peer doesn't forward such messages, but that's +easily solvable by making a few more connections. All clients should warn +their users that having only one 'connection' is dangerous. + It's easily then to make the client to read a mailbox for the incoming +requests (or a IMAP folder, or some filtering mechanism in the mail reader), +and use SMTP for all outgoing requests. That should make a somewhat +transparent peer-to-peer network. + There isn't a problem for communities to use the same method, they'll +behave like mailing lists. + + + Appendix B. "Native" transport layer + + + This method is heavily influenced by keyservers and irc networks, +because they both have managed to survive and provide (somewhat) useful +service for communication. + + The method consists of tracker services, keyservers, and clients. + + B.1) Keyservers + + The keyservers hold a copy of all the keys, signatures and revocations. +Every client, tracker or other keyserver can request information about +some keys, or all the entries after a certain timestamp. All the keyservers +keep in sync through some method of exchanging updates, like email, or +direct TCP connections. There is no requirement for further encryption +of the channels, only a identification and a signature to every request +by the server, to avoid inserting rogue requests. All keyservers have +to sign each other's keys, and to approve each other's existence. That's +required, so there won't be fake keyservers to pollute the database with +fake keys, and to slow down the operations. +(the email method for exchanging information between keyservers is +purely exemplary, and probably not suited for wide deployment). + +The requirement for multiple servers it to reduce the load. The load +consists mostly of reading, and with some updates, of which most are +append operations. That kind of load is one of the best to distribute +between multiple systems. The task is made easier by the fact that +there can't be conflicting updates, only duplicates in some worst case +scenarios. +There are two scenarios about the interconnection of the keyservers. +One is to create a spanning tree topology, like irc networks, which is +optimal for update propagation in terms of bandwidth usage. This method +has some disadvantages, like 'splits' (dropping a link between 2 servers +means that some part of the network can't reach the other until one +of those servers connects to the other part in some way). +The other scenario is to create a more connected tree, in which the updates +to propagate in the following fashion - a received request is sent to all +peers except the one that it was received from, unless it was already +received from some other node/connection. This method can give every +keyserver 2 or more connections to the network, which can be redundant +enough so the keyserver won't suffer any delay in the updates. The downside +is that some servers will receive some requests more than one time, and +this will waste bandwidth. Judging by the design, updates won't be a +big traffic generator, except in cases where new server joins and +retrieves the database, which is clearly localized. + + There is one problem with this idea, that every server has a copy +of the database of trust and public keys. If that information is valuable +for somebody, it's probably easy for retrieval (as in current keyservers, +you'll just have to get some public key id's from the web, and then to +follow the signatures). For the whole system to work, this whole database +has to be available to it's users and servers, so any user can get it in +some way. + + B.2) Trackers + + The idea of trackers is to give the clients a way to deliver to each +other requests. Trackers are a network, that carries the following +information for all clients connected to it: key id, methods for direct +delivery, and tracker which stores requests for this id. + + The mode of operations is as follows: every tracker exchanges data about +it's users with the trackers he has connections with, provides this +information on request to its users, and receives information from +its users about their parameters. It then can forward users' requests +to another tracker, and send to it's users requests from another users +on the same network. And some users can register at a tracker to have +something like a 'mailbox' there, so anyone can send requests/replies +to her/him, that will wait until his/her new session. + + The method for direct delivery can be email address, host:port pair, +or whatever transport method is available. So, if client A wants to +exchange information with client B, like to check if there are profile +changes, or to send some information to update A's profile to B, A can +get the information from it's tracker, and then use it to communicate +with B directly. And if B isn't connected to the tracker network, or +didn't provide a direct connection method, wanting to hide his location, +the trackers can deliver this to it without revealing it's location. +This mode of operation can be compared to ICQ's direct connection and +sending through server. + + Having an account/mailbox on a tracker is something that's negotiable +between the user and the tracker, and a policy issue for trackers. + + All trackers must have a way to validate keys, through a keyserver, +or through a read-only access to it's database. + Access to the trackers is validated through the keys of the users. +Trackers can require the users to have their keys signed directly +by them, to have signature from any tracker, or a trusted signature +by any other trusted user (e.g. signed by this tracker or the others). +This could be needed for load-balancing purposes, and network topology +reasons.