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

[Tao Effect]

Hi Marcela,

Thanks so much for the quick reply!

> 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.


Well, I meant that Bob has the strict policy set, and that Alice sees that and therefore only accepts a new key from Bob if it’s signed by his previous key. But your answer seems to also apply to Bob?

> 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.

Yes that would be great, I'd very much like to read that. :-)

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

Thanks! I’ve signed up! ^_^

Cheers,
Greg

> On Mar 21, 2016, at 11:35 PM, Marcela S. Melara <melara at CS.Princeton.EDU> wrote:
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160321/68aa8777/attachment.sig>