[messaging] Key rotation

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/01/15 17:44, carlo von lynX wrote:
> Alright, let's say when the two devices see each other
> successfully they emanate a gentle notification indicating they are
> syncing up and available for further exchanges like playing a game
> together.
> 
> When that does NOT happen, Alice and Bob may not notice the first
> or second time but at some point they may wonder why there was no
> signal, no exchange or simply why they can't do stuff together as
> they usually do with others.

I'm not a usability expert, but I believe there's a design principle
that says people don't notice the absence of a signal. Hence we have
warning lights that appear when something's wrong, rather than
"everything's cool" lights that disappear when something's wrong.

> Not being aware of the potential semantics of this failure, they 
> would probably just restart a key handshake as when they add a new 
> person. This probably involves the QR codes you mentioned:

Maybe - we'd need to test this. They might just consider it a weird
bug and ignore it. Bluetooth is flaky, after all...

>> * Alice or Bob may have selected the wrong contact from their
>> contact list to validate * The third party who introduced them
>> may have carried out a MITM attack * Alice may be lying to make
>> Bob think that the third party carried out a MITM attack, or vice
>> versa
> 
> At this point Bob is prompted if he just met a new Alice, or if the
> old Alice is indeed to be replaced.

The adversary can make it tricky for the app to detect that Bob
already has a contact with the same nickname - for example, the
identity supplied by the adversary during the MITM may have the name
"Alice ", "A1ice", "Al\u00A0ice", etc.

And of course, Bob may really know two people called Alice. When he
adds the second one, we don't want to force him to choose between
replacing the first one and getting a scary security warning.

> If Bob confirms that Alice is to be replaced, then your application
> can inform Bob that the communications that went to Alice
> beforehand may have been tapped.

Sounds good - I like the idea of just explaining what may have
happened without trying to attribute blame.

> If Bob chooses to create a new Alice, then the two may coexist for
> as long as either Bob or the application do not understand he's got
> the same person twice. Should that awareness come about later, the
> Alice that was confirmed by physical vicinity is preferred over the
> Alice that got acquired by unsafe methods.

We'll have to give some more thought to how Bob might act when he
realises his two Alices are the same person - perhaps he'll look for a
"merge contacts" feature, which could then behave as you described?

> If Alice has been lying to Bob while standing next to him, then she
> doesn't really want to be his friend. That isn't nice, but it only
> results in Alice appearing unsafe to talk to from Bob's phone,
> which probably corresponds to reality.

No, the problem is that if we use language that suggests that Carol
(the introducer) has been trying to intercept Alice and Bob's
conversations, then Alice can present a false identity when Bob
verifies her in order to cast suspicion on Carol, while Alice looks
trustworthy.

> Ultimately, if both Alice and Bob want Jake's advice whether their 
> communications had been tapped, Jake can look at the detailed event
>  logs of both devices and do some forensics on those to try and 
> figure out what really happened.

Even if we suppose that Alice and Bob know a suitable Jake, there's no
way to tell by examining the logs whether it's Carol or Alice who's
untrustworthy. (Alice can forge her own logs.)

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUr/CZAAoJEBEET9GfxSfM5FkH/iNzsOYQ66QgC3wyoB+yfsLH
IupS7VxS8KOVfiEhARllIrxmjc+SSrCartNVnaWGx8c+05RjpCCNjI/McoY//vjJ
v1NMGb60E40qyveI0a33V92i/kRJIiJfF3RC6BveSoW8O/iI4jlC5AStYf71EIDZ
4lkt8WhOpf888QXFC5EKd7K30ylwi0zuP97k4V9y2pRewYjqKPuUKVvKnbP6YDCG
+hk430ubMzLyUx/C64r4fAI1PlQqo/g44ONDI01FVj7XL56YsDkhSg0FRbkhVkO/
KVyMfCMTyoY1PbJd9V9RWp/QRhaB3LJj+WKxpficvixIvFEi/WlAJoao3RgZuyM=
=h/HG
-----END PGP SIGNATURE-----