[messaging] One CONIKS or many?

[Marcela Melara]

> On Mar 24, 2016, at 11:51 PM, Watson Ladd <watsonbladd at gmail.com> wrote:
> 
> On Thu, Mar 24, 2016 at 8:32 PM, Marcela Melara <melara at cs.princeton.edu> wrote:
>> 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.
> 
> So if we have an instance for Punr and another for Swiftery each
> storing keys for one of them, they will audit each other?
> It seems
> that auditing a single service is more likely to happen/we can't rely
> on servers being independent when centralized messaging providers have
> to run them.

So I think there’s some confusion about using the terms messaging service vs messaging provider. Joe and I tend to use the two synonymously, which clearly isn’t 100% accurate. You’re right in saying that it makes more sense for a centralized communication provider which runs multiple secure communication services (e.g. someone like Apple who run iMessage, FaceTime etc) to run a single CONIKS key server. What Joe and I were getting at is that it makes less sense for *multiple* centralized secure messaging providers (e.g. Apple and Open Whisper Systems) to share a CONIKS key server. 

This doesn’t mean that these centralized providers can’t serve as auditors for each other, as long as they are willing to interoperate for auditing. If there are multiple centralized providers who are willing to interoperate for auditing, you may not need as many additional third-party auditors. That’s not to say that having third-party auditors isn’t also beneficial for the security of the system.