[OTR-dev] mpOTR protocol phases and research questions

[George Kadianakis]

Callme Whatiwant <nejucomo at gmail.com> writes:

> On Wed, Oct 23, 2013 at 8:26 AM, George Kadianakis <desnacked at riseup.net> wrote:
>> Here are some more notes about mpOTR that I refreshed today.
>>
>> Here are some properties that the mpOTR protocol should have. These
>> were also mentioned in the mpOTR paper:
>>
>> - Confidentiality
>> - Entity Autentication
>> - Origin Authentication
>> - Forward Secrecy
>> - Deniability (Repudiation/Malleability)
>>   Do we want this? It would certainly be nice to have, but it makes
>>   things so much harder!
>> - Transcript synchronisation
>> - ...
>>
>> Here is a breakdown of an mpOTR session in phases:
>>
>> [Channel establishment] -> [Authentication] -> [Key exchange] ->
>> [Communication phase] -> [Shutdown phase]
>>
>> At the moment, the [Authentication] and [Key exchange] phases are the
>> ones that need the most attention from researchers. More details
>> below.
>>
>> Phase breakdown:
>>
>> [Channel establishment]
>> * Where a set of initial unauthenticated participants is selected and
>>   a channel between the participants is established.
>>
>> Notes:
>> - I assume that the protocol is centralized since it makes
>>   everything much easier (I assume that broadcast happens by
>>   sending a broadcast msg to a server). We can decentralize
>>   later.
>>
>> Solutions:
>> - Assuming an application-agnostic protocol, this can happen using IRC
>>   channels, or XMPP MUCs, or SIP or whatever.
>>
>> [Authentication]
>> * Where participants authenticate each other and a set of
>>   authenticated participants is established.
>>
>> Notes:
>> - At the end of this phase, each participant should be confident
>>   that he trusts all the other authenticated participants.
>
> I'm not sure what this actually means.  Can we rephrase it to be more specific?
>
> The only protocols I know of that "should make me confident that I
> trust another participant" involve tweaking my body chemistry or
> neural function.
>
> Do you mean to say at the end of this phase, a participant has some
> session state (such as a shared pairwise secret) which is
> authenticated to another party's public key?  Do you mean something
> else?
>

Hi,

I meant that at the end of that phase, a participant X should be
confident that participant Y controls the private key that corresponds
to the public key that X had assigned to him in the past. This is the
same authentication logic as in OTR.

Ideally, each participant X should authenticate in this manner all the
other participants (There are protocols which only authenticate the
adjacent participants of X and assume that all participants are
authenticated in a cyclic fashion).

BTW, I did not try to make my post cryptographically robust. I just
explained some concepts with words. On purpose, I did not expand on
what happens when X has not assigned a public key to Y. Or whether
mpOTR should have other authentication methods except public-key-based
(for example, in OTR there is SMP).