[coniks] Questions for okTurtles CONIKS review

Tao Effect contact at taoeffect.com
Sun Jan 15 21:05:17 EST 2017

Dear list,

I am very impressed with CONIKS. As part of my work for the okTurtles Foundation, I research and review various proposed solutions to the public key exchange problem.

We previously wrote a three-part series on Google's Certificate Transparency [1], in which we identified various design and security problems with the system. I just finished reviewing the CONIKS 2.0 paper by Michael Rochlin and I'm very pleased to see that the approach CONIKS has taken is both far simpler and more likely to provide meaningful security improvements to the web.

That said, the paper left open some potential issues, and before I sit down to write a comparison of CONIKS to Google's CT (and other approaches), I would like to first check my understanding and see if my concerns are unfounded.

Here are my 4 questions, thanks so much for helping me understand CONIKS better:

Question 1: Is there a formal RFC-like specification for CONIKS being developed, and if so, where is it?

One significant concern that I had while reading the paper is the use of "should" in places where I would have expected the word "must" to be. This was especially notable on page 10 of the document.

In IETF-style RFCs, the words "should" and "must" have very specific, concrete meanings when it comes to determining whether an implementation conforms to the specification or not. Many of the "should"s on page 10, should (heh) have been "must"s if CONIKS is to provide real security guarantees.

For example:

- "[..] she should report it publicly as a violation"
- "Providers should sign all key changes done on behalf of users with their own public key."
- "[..] he should find either a signed key change from Alice or a signed change from the provider."
- "[..] it should alert the user."


Were these just oversights, or are these "should"s to be interpreted per SHOULD in RFC 2119?

Question 2: Is all of the data, including the options, ALWAYS signed by the user's public key?

There is a very curious `allowsUnsignedKeychange` flag that could undermine all of the MITM security offered by CONIKS, but only if its setting is not signed by the user's registered public key.

Is this setting, along with all over settings/options/data/configurations signed by the user's public key? Or can it be signed by the server's public key, or not signed at all?

Now, we understand the rationale behind the "allowsUnsignedKeychange" option, however there are ways to solve the "lost private key" problem that do not require users having to trust an untrustworthy provider (and in our opinion, all key transparency providers are to be considered untrustworthy).

This brings us to Question 3:

Question 3: Will CONIKS force users to trust untrustworthy entities for private key resets, or will CONIKS allow users to specify the entities whom they trust to re-create their identities for them?

In DPKI [2], we solved this problem by allowed the user to specify the entities that they trust to restore their identity for them. This can be accomplished simply by letting the user specify the public keys and the n-of-m parameters (of those keys) that is necessary to create broadcast a message that signs a new public key on behalf of the user.

Example: Alice loses her phone. Alice uses the app to generate a new keypair and sends a request to the friends she authorized to sign it.

Question 4: What "password"?

On page 9, there is a strange sentence that is not elaborated, "If for some reason Alice forgets her private key, she can ask the provider to reset her password."

This sentence does not make sense for two reasons:

1. Nobody remembers their private key.
2. A password is not a private key.

What password is this and how is it associated with the private key and how can the provider "reset" it without overriding the private key?

Thanks so much!

Greg Slepak
okTurtles Foundation


[1] https://blog.okturtles.com/tag/certificate-transparency/ <https://blog.okturtles.com/tag/certificate-transparency/>
[2] https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf <https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf>

Please do not email me anything that you are not comfortable also sharing with the NSA.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/coniks/attachments/20170115/5f87ab9d/attachment.html>

More information about the coniks mailing list