[messaging] Verification of strict key change policy in CONIKS?

[Marcela S. Melara]

Hi Greg

> On Mar 21, 2016, at 22:56, Tao Effect <contact at taoeffect.com> wrote:
> 
> Dear list,
> 
> Questions for Joseph, Marcela, or any other CONIKS experts out there:
> 
> Regarding the strict key change policy mentioned in the paper, how can Alice verify Bob’s latest key? Does she cache his previous key and verify the latest one received comes with a key-change message that’s signed by the previously cached key?

I'm assuming you mean Alice is the user with the strict key change policy in this example? So yes, Alice's client would see the strict flag set as part of Alice's user metadata and would know to cache Bob's key and only accept a new one if the key change is authenticated with the cached key. 

> This aspect doesn't seem to be part of the protocol described in the paper. If there is a way to securely verify the key change using a previously verified/pinned key then this mechanism could prevent MITM attacks.
> So is this specified in an “official protocol” somewhere?

Right, the specification of the key change protocol was actually a follow-up project I worked on with an undergraduate, who wrote his junior research paper on it. He also implemented this protocol, and getting it merged into our reference implementation on GitHub is in the works. In the meantime, I can get his junior paper on the CONIKS website.

> Also, is there an official discussion list for CONIKS?

There is, you can sign up at coniks.cs.princeton.edu

> 
> Thanks much!
> Greg
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging