[messaging] Key rotation

[carlo von lynX]

Hope it'S ok to brainstorm on this scenario a bit...

On Tue, Jan 06, 2015 at 12:54:12PM +0000, Michael Rogers wrote:
> I think that's a great idea, and we're planning to do something like
> that in Briar. The difficult part is the UX.
> 
> The protocol has to be kicked off manually, because if a MITM attack
> *has* taken place, Alice and Bob will be using different keys and
> therefore won't be able to establish a secure Bluetooth connection
> automatically. (That failure in itself isn't a useful signal of an
> attack - Bluetooth's flaky.)

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.

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:

> So we're probably looking at a workflow based on QR codes, where each
> code contains a Bluetooth address and an ephemeral public key for
> securing the connection, independent of the key material being validated.
> 
> Let's say Alice and Bob scan each other's QR codes and detect that
> they've been using different keys. What should they do? This is the
> hard part, because there are several reasons this could happen:
> 
> * 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. 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. 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. 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.
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.

Makes any sense like this?