[OTR-dev] mpOTR: shutdown()

[Abel Luck]

Arturo Filastò:
>> Question 1: How do we determine when a user has "left" due to network
>> timeout/instability vs simply quitting?
>>
>> Relevant section of specification:
>>
>> "When users wish to join or leave a chatroom, the proto-
>> col shuts down the current session and then calls Initiate()
>> with the new set of participants to initialize a new chat ses-
>> sion." (pg 7)
>>
>>
>> I propose a timeout of some number of seconds. Thoughts?
> 
> I think this is a quite reasonable assumption, though the problem is
> that the
> client that left will not have participated to the shutdown phase and
> therefore
> they will loose the deniability property.

Yes, unfortunately, that is unavoidable. Since shutdown() is so
important, the client should definitely prioritize the shutdown.

What sort of timeout do we want to use? This might depend on the group
decides to initiate shutdown (see next).

>> Question 2: How do clients decide to initiate Shutdown()? What happens
>> if some clients initiate it but others do not?
> 
> The shutdown() is invoked when a participant wishes to leave the chat and
> it requires everybody in the group chat to participate to such phase.
> 
> It is blocking with respect to any member of the group.

So, Alice wishes to leave and invokes shutdown(). Alice's client blocks
until it completes. Every other participant receives the request and
responds, likewise, their clients block until shutdown completes.

How do we error out? What if the network of Alice is disrupted while
blocking for a shutdown()? What if the network of another participant is
disrupted while Alice is blocking? We need a similar timeout for the
shutdown() phase.

There are probably more error cases here than this too.

> Question 3)
> What happens if a person joins during the Setup phase?

Been wondering the same myself. A similiar question is, what if the
group decides Alice has left (due to timeouts), and is in the middle of
a shutdown()+setup() when she joins back in. Can we just cancel the
ongoing shutdown/setup and reuse the existing session?


> In the first case I see a possibility for malory doing bad things. In
> the first she can
> keep joining the group chat with new nicks and prevent anybody from ever
> completing
> the setup.
> Would the second strategy work?

A DoS is definitely a possibility.  Rolling over from one session to
another seems to be a good solution, especially to preserve the
continuity of the conversation.


> Question 4)
> What is the solution to message replay attacks?
> This was already discussed on this mailing list [1]. In the end no true
> solution
> to this issue was found and it was stated that this would be the topic
> of future
> work [2], does someone know the status of such work?

Going to read this and think about it before I respond.


> I have another few questions, but will keep them to myself for the
> moment or start another
> thread with them as I think they may be a bit more controversial.

Definitely start another thread if it's an issue. We want to get mpOTR
implemented for real, so we need to address it all :)

~abel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20120718/0c37d570/attachment.pgp>