[messaging] One CONIKS or many?

[Marcela Melara]

I would add a couple of things to Joe’s explanation as to why having a single CONIKS service for many is probably disadvantageous. 

One is that CONIKS is designed in such a way that it provides stronger security when there are more participants — in particular auditors — in the system. Though CONIKS key servers don’t necessarily need to act as auditors in practice, our original thinking was that the system would be less complex (i.e. require fewer parties in addition to the key servers) by having the key servers act as auditors as a way to cross-verify each other. So by having the auditing code for everything in one place, you’ve essentially reduced the number of auditors to one (at least for all of the messaging services relying on the one CONIKS service), which weakens the overall security of the users of the one CONIKS service.

The other point is about privacy. Even though individual users’ privacy may be preserved with respect to each other, it’s not clear that the various secure messaging service providers would be willing to disclose their user base (and the size of this user base) to some other party.

The case of Tor Messenger is kind of unique since Tor Messenger provides the end-to-end encryption and key management for many insecure communication services (e.g. Twitter). But in a sense Tor Messenger really is a single secure communication service, only that they are able to handle a wide variety of user identifiers from the various communication services they support. So it makes sense for Tor Messenger to provide a default CONIKS key server for their users because they are already mapping keys to each individual user identifier. What’s important is that each identifier (e.g. @alice) can remain unique in the Tor Messenger namespace. Then the challenge becomes a matter of verifying that the rightful owner of @alice on Twitter is also the owner of @alice in Tor Messenger. Maybe this was already clear to people, but I thought it was important to clarify this case in the context of this discussion.


> On Mar 24, 2016, at 10:01 PM, Joseph Bonneau <jbonneau at cs.stanford.edu> wrote:
> 
> There are certainly some appealing things about having one server that multiple messaging services can rely on. On the whole though I've felt there are more drawbacks than advantages.
> 
> Two underlying premises of CONIKS though are that each service provider controls its own namespace (who gets to sign up for which name) and key recovery (by non-cryptographic authentication). The whole point of CONIKS is to ensure that multiple users have a consistent view of what key belongs to a name like "jbonneau at cs.stanford.edu <mailto:jbonneau at cs.stanford.edu>". Users can opt-in to having a key-signing key to avoid relying on the directory for key recovery, but the directory still at the very least hands out names to new users.
> 
> If you want to have one directory representing multiple namespaces, you still need to have each provider sign new additions to its namespace (as well as many of the updates). You'll also might want some way of preventing one provider from DoSing the system by registering billions of users (the proofs would still be short but somebody has to store all of that data).
> 
> You also need everybody to agree on one epoch length and different providers might want different things.
> 
> Proofs will also get larger. Only logarithmically so, which isn't terrible, but for centralized systems (which CONIKS was really designed for) like iMessage or Signal, you can't communicate across providers so there is no benefit sharing a directory. 
> 
> I should read the tor-dev threads, but what's the ultimate goal with Tor Messenger-to have one built-in key server that the software uses by default, or to have users pick their own key server?
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160324/ec26505b/attachment.html>