[sugar] Obtaining Buddy objects as contacts are encountered

[Sjoerd Simons]

On Thu, May 10, 2007 at 04:32:35PM +0100, Simon McVittie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At the moment the Presence Service API assumes we're subscribed to the
> presence of every contact we'll ever encounter, which obviously can't scale to
> a school.
> 
> When child joins an activity we're in, the presence service needs to be able
> to give us a Buddy object for them without making network round-trips -
> otherwise the activity will have no way to identify them. We can't just ignore
> them (omit them from the GUI) until we've made network round-trips to ask
> the server about them, because they might start participating in the activity
> before we get the server's reply, and it would be confusing to get messages
> from an apparently nonexistent buddy (also, activity authors are
> unlikely to handle this correctly).
> 
> At the same time, we don't want to have two Buddy objects in the PS process
> representing the same child, and have to do some sort of coalescing process
> when we work out that they actually represent the same person; so from just
> the information we immediately have when we first encounter someone,
> we should be able to make the decision whether two contacts are in fact the
> same.
> 
> For the server case, the JID is constructed as follows:
> 
> 	hex(sha1(public key)) + '@' + configured server
> 
> To avoid spoofing we need to require that the server will only create new
> accounts (or almost equivalently, allow login to an account) if the client can
> demonstrate knowledge of a private key for which the public key's hex SHA-1
> is the username part of the desired JID.
> 
> For the link-local (mesh) case, I believe the idea is that the public key
> and other OLPC info is in the mDNS record, so by the time we can interact with
> someone, we already have all relevant information about them? If so, and we
> put the corresponding server-JID in the mDNS record, then we can again always
> know which child we're talking to.

Correct. Well it could potentially happen that someone connects to you before
you resolved his/her mDNS record. But that window is neglibally small (Salut
currently even refuses your connection if it can't link you to a known mDNS
record)

> Again, to avoid spoofing we need to require that the mDNS record demonstrates
> knowledge of the private key; perhaps it could include a signature of the IP
> address or IP:port or whatever, and a timestamp, made using the private key.

Yes. Although signing doesn't win you much as others can easily spoof your mDNS
record as soon as they've seen it. If we make it mandatory to refresh your
signature every once in a while, the damage can be limited though (You can be
only spoofed for a limited timespan).

If we case we to make it even better, we will need signed records in avahi
itself.  So avahi can sign each record it sends out.

The most important thing is that we need to prevent spoofing when we start 
interacting with someone though. Spoofing that someone is on the network/in
some activities is bad, but a lot less harmless then interacting with someone
that isn't who he says he is.

This brings up a major issue though. What should happen if we see a presence
we've never seen before and thus don't know what the public key should be.
Should we take a leap-of-faith and trust that person or we do some magic 
handshake to determine his/her identity ?

In the same line of thinking. If we established someone is actualy
<random hash>@school.example.com. Who is actually authorative to say what human
readable presence information belongs to him (name, colors). Especially in
link-local you can just put any information you want in there.

  Sjoerd
-- 
The truth of a thing is the feel of it, not the think of it.
		-- Stanley Kubrick