[messaging] Multiple devices and key synchronization: some thoughts

[Trevor Perrin]

On Tue, Jan 6, 2015 at 4:08 AM, Michael Rogers <michael at briarproject.org> wrote:
>
> On 06/01/15 00:18, Trevor Perrin wrote:
>> (e)
>> Changing this "identity info" may be costly for Bob (telling all
>> his correspondents his info changed, changing a bunch of
>> registrations, getting new certificates, printing new business
>> cards, etc).
>> (f)
>> Alice can lookup Bob's shorter-lived and/or
>> one-time "prekeys" from some service (either centralized, or hosted
>> by Bob's provider) which is not trusted for confidentiality or
>> authentication.
[...]
>
> Let's take the costs you've outlined in (e) one at a time.
>
> Correspondents: Bob's correspondents are automatically introduced to
> the new device by his existing devices. No effort for Bob.


I think you're saying that when Bob gets a new device and introduces
its public key to one of his existing devices, the existing device
could send a message to all of Bob's correspondents informing them of
the new device?

That seems worse than the other options.

What if Bob's device doesn't remember every correspondent?  What if
Bob has cleared history, or isn't aware of everyone who has cached his
"identity info"?  What if Bob has ten thousand people he's ever
corresponded with?  What if some of them have changed their address,
or are temporarily unreachable, or the message gets lost for some
other reason?

My argument is that instead of updating everyone that might be
remembering your identity info, it's easier to leave that info
unchanged and just sign the new device's key, or synchronize the
existing private key to the new device.


> Registrations: We've left open the question of where Bob's info might
> be registered (servers, DHT, etc), but again, any of Bob's registered
> devices can automatically authenticate the registration of the new
> device. No effort for Bob.
>
> Certificates: I'm not sure what you have in mind here. If you're
> imagining that this will tie into some existing hierarchical PKI then
> I guess it does make sense to continue the hierarchy and have a master
> key that certifies device keys.
>
> Business cards: You know what I think about this use case. :-)


We could work through every possible infrastructure you might use your
public key with, but I think the general point stands: the less often
you change your public-key / fingerprint and have to redistribute it,
the better.

Tackling this another way: You're assuming Bob informs his existing
device of the new device's public key.  At this point, it's easy for
the existing device to sign the new device's key, or encrypt the
master private key to the new device.

Since there's little cost to these, why not do one of them?  Do you
feel there's some problem with signing device keys, or synchronizing
the master private key?

-

Side note: I'm arguing here that we should keep a user's "identity
info" stable when adding devices.

But with David, I've argued it's not worth supporting revocation that
would keep this info stable while revoking a device key.

The reason is I think the former is easy (sign or encrypt to the new
device's public key), whereas I think revocation is much more
complicated and problematic.


>> The most practical approaches are probably either synchronizing
>> the identity key between devices, or using it to sign device keys.
>> Either way, adding a new device might increase communication in
>> (f), since Alice might have to retrieve additional device-specific
>> prekeys, and/or signed device keys.  But adding a device would not
>> incur the costs in (e), which is more important.
>
> Why is it more important? Presumably (f) happens more often than (e).

In systems like TextSecure or Pond, Alice has to contact Bob's server
to deliver the message anyways.

So having Bob's server tell Alice "oh, Bob has a new device, here's
its signed key and prekeys" when she goes to deliver a message is
easy.


>>>> If you require interaction with one device to learn about
>>>> others, you lose "asynchronousness", and I'm not sure what you
>>>> gain.  If you're using different device keys not signed by a
>>>> single key, you lose fingerprint-ability.
>>>
>>> The process by which a device introduces a contact to its
>>> owner's other devices is asynchronous.
>>
>> That's not asynchronous enough for email / text-messaging though
>> (b, c).
>
> Sorry, I don't understand what you mean by "not asynchronous enough".
> It could literally operate over carrier pigeons.

I thought you were talking about an interactive communication with the
introducing device.  Now I think I understand you're talking about the
introducing device just sending a message to correspondents.

That may be better, but see issues above.


>> I probably depends on your assumptions / use cases.  If you only
>> establish connections face-to-face that can be authenticated via
>> device pairing (QR codes, SAS, etc), then you may be right that
>> having a single identity public key doesn't get you much.
>
> I'm not assuming that all connections will be face to face. Face to
> face connections are only required (a) to add a contact and
> immediately know you're using valid key material for them, or (b) to
> validate key material you've been using for a contact who wasn't added
> face to face.
>
> If we assume there's no totally trustworthy third party, and no
> self-authenticating channel other than face to face, then these
> operations need to be face to face for any of the options we've
> considered, don't they?

I don't agree with those assumptions.  Or at least, there's a huge
difference between:
 - a single third party that everyone trusts for everything
 - context-specific third parties that particular Alices trust to
inform them about particular Bobs

I agree the former doesn't exist, but the latter ones do, and those
are channels I want to send "identity info" like fingerprints through.

Trevor