Name Resolution

The main function of the resolution component is to map names to their corresponding result sets. To reduce the overhead, the resolution component makes use of proactive caching with Data Stores replicating name to result set mappings. This replication makes use of the fact that each person will likely only interact with a small number of people. The overhead for replication should be quite low as a result.

However, recognising that this replication will not always succeed the component also provides an interface to hosts to access its result set. This functionality is only accessed when a person deems their result set to be out of date. In this way the latency involved in resolution is reduced, while replication failures are handled gracefully.

In Fig. 3.6 we see the basic message flow of the resolution component. Updates flow through the Data Stores from user devices. The use of the Data Store as a means of sharing state between user devices was outlined in the previous section.

Fig. 3.6: The name resolution message flow

3.7.1

Resolving Identifiers

Name to result set mappings in Sobriquet may require authentication before they can be viewed. This is to prevent harvesting of Application Specific Identifiers through the resolution function. If authentication is required before a given person can query results then this is stored in plain text in the privacy field at the Data Store alongside the SGN and its results. If the user has chosen to require authentication before its result set is provided to a client, then the Data Store must require authentication from the client issuing the query. The authentication protocol used between a client and the

Data Store is outlined in Section 3.4. Additionally the Data Store must not override the preferences regarding requiring authentication from the client.

Each entry in the Data Store is indexed by its SGN. Each SGN maps to a single set of results. While updates are generally pushed from the Data Stores to each of a user’s devices, a query may also be performed by a user device to the appropriate Data Store directly. If there is an updated result then the result is synchronised between the user device and its Data Store. This ensures the updates are disseminated to all of the other devices belonging to the user.

We use a vector clock to determine the latest update, with each update tagged with a counter value that is incremented by the client when it is pushing an update to the Data Store. The Data Store can determine if each client has an up to date result set at each point. In an update the client pushes a complete result set, as opposed to just the changes, and so the Data Store can just overwrite one if it is newer than the one it currently has. If the Data Store sees two clients try to push different updates with the same counter value then it can simply accept the first one, and reject the second, forcing that client to retrieve an update and retry pushing its changes later.

The Data Store is responsible for pushing updates to result sets to each of the user’s contacts. Since these are signed using the group manager’s private key corresponding to the SGN the result set is tied to, we can trust the Data Store to do this on behalf of the user. Since only the owner of an SGN can produce signatures for that SGN, only they may push signed updates for that SGN. This signature is verified by each SGN before the updated results are written to the relevant tables.

When an update is pushed from the client, the Data Store can perform a lookup in its database to obtain the list of contacts associated with the SGN that the user’s result set has changed for. This is the list of clients that need to be sent the updated result set. The Data Store will contact the Data Store of each member of the Contact Group corresponding to the updated SGN namespace and push the new result set to them. In doing this it will send the contact’s Data Store the SGN of the contact so

their Data Store knows which user table to lookup, and the updated result set. The Data Store can then update the contacts table for the relevant users in its database. If multiple members of a Contact Group use the same Data Store then this request can be batched by sending multiple target SGNs in the update. The Data Store receiving the pushed update will then update each of those tables.

There are two scenarios which can result in a result set being queried from the Data Store as opposed to the local cache. The first is when the cached copy on the user’s device becomes stale. This occurs after a predetermined amount of time or if the cache is invalidated by the user. In this case a query occurs in order to freshen the cached copy on the device with the most up to date version at the Data Store.

The second scenario is when the user attempts to initiate a communication session with one of their contacts and a failure occurs at the authentication step. The user initiating the session will then check their Data Store for an update from the person they are attempting to contact. If they determine that there is none then authentication is deemed to have failed. It is up to the initiator whether they want to retry later. An active attacker could in this instance cause a denial of service by interfering with all authentication sessions between the two users; however we believe this is an acceptable risk. Such a failure does not result in a new identifier exchange and so the attacker cannot use a denial of service in this case to force new identifiers to be created and attempt a man in the middle attack at that point.

In Fig. 3.7 we see how Sobriquet fits into the data flow of a typical internet com- munications application. Our naming system performs resolution on an identifier that represents a person and maps it to a set of application specific identifiers. On contacting each other each party can authenticate each other to their global identifiers.

Fig. 3.7: A typical internet communications session with Sobriquet.