2 Use cases that cause problems if Alice is only one able to send the first data message

[cobratbq]

As follow up to https://github.com/otrv4/otrv4/issues/147, if I understand your explanation correctly, this will cause problems in the following 2 use cases:

1. A secure conversation is initiated by Alice immediately sending an Identity Message to Bob. (As described in Starting a conversation interactively.) In this case Alice is the one that is initiating, and sending the Identity message. Hence she ends up waiting for Bob's first message. Bob however, may not be aware that a secure session is being set-up (if this happens in the background, depending on IM client behavior) or is not available/aware that he needs to send the first message. Therefore, Alice has no way to initialize the Double Ratchet and cannot send a message.

2. Alice sends a whitespace tag or query message and is received by multiple clients of Bob, that respond. Each follows the Interactive DAKE protocol and all end up in an ENCRYPTED_MESSAGES state without Double Ratchet being initiatlized. Alice will pick only one instance to chat with, that is the only one initialized. All other instances of Bob are stuck in limbo as a) Initialization of Double Ratchet does not complete, and b) Bob is not expected to send new query messages as he (and also Alice) is already in ENCRYPTED_MESSAGES mode.

I wonder if there should be a mandatory first data message such that we can ensure initializion fully completes for both parties. Alternatively, I can be completely wrong. I did not find any information explaining how these issues are mitigated though. Granted, I don't know the spec by heart.

[claucece]

Hey!

Thanks for this!

For the first use case:

A secure conversation is initiated by Alice immediately sending an Identity Message to Bob. (As described in Starting a conversation interactively.) In this case Alice is the one that is initiating, and sending the Identity message. Hence she ends up waiting for Bob's first message. Bob however, may not be aware that a secure session is being set-up (if this happens in the background, depending on IM client behavior) or is not available/aware that he needs to send the first message. Therefore, Alice has no way to initialize the Double Ratchet and cannot send a message.

Alice is the one that initializes the conversation by sending a query message or a whitespace tag. She is not the one sending an identity message (in the overview). Bob sends the identity message. Therefore, it is Alice the one that sets up correctly the double ratchet, and sends the first data message. As in any case, she expects for setting up the conversation the correct DAKE messages from Bob but no double ratchet initialization from him. In the case of starting the conversation interactevly, please note how the double ratchet is initialized here: https://github.com/otrv4/otrv4/blob/master/modes/otrv4-standalone-mode.md Note that she does not wait from any message from Bob in order to send a data message.

[cobratbq]

For first use case: The normal use case is indeed not a problem. I mean specifically the case where you start without sending a query message first. (Hence my reference to the "Starting a conversation interactively".)

I see that the conversation steps are different for stand-alone mode. Are you planning to describe that in otrv4.md? It was my understanding that otrv4.md document is the total spec and the rest were documents for clarification. (This may be a bad assumption on my side.) I would at least refer to the otrv4-standalone-mode inside the "Starting a conversation interactively" section. It now gives a false impression that there is only a single variant of the Interactive DAKE protocol while the Standalone Mode one is significantly different. (And for initiating with a Identity Message, the "Interactive DAKE protocol" outline does not hold.)

[claucece]

Hey!

I see that the conversation steps are different for stand-alone mode. Are you planning to describe that in otrv4.md? It was my understanding that otrv4.md document is the total spec and the rest were documents for clarification. (This may be a bad assumption on my side.) I would at least refer to the otrv4-standalone-mode inside the "Starting a conversation interactively" section. It now gives a false impression that there is only a single variant of the Interactive DAKE protocol while the Standalone Mode one is significantly different. (And for initiating with a Identity Message, the "Interactive DAKE protocol" outline does not hold.)

Yes, I completely agree. After discussion here with the team, I think we found a way to unify them. I'll start to change this and update this issue accordingly :)

Thanks so much!

[claucece]

Hey!

I have introduced heartbeat messages to not let the different clients of OTRv4 in the limbo. Still, we have to find a better solution.

I see that the conversation steps are different for stand-alone mode. Are you planning to describe that in otrv4.md? It was my understanding that otrv4.md document is the total spec and the rest were documents for clarification.

No, only the ADR are for clarification. The different way modes work will not be described in the main document, as this one links to the modes:

For details on how these modes work, review the modes folder.

I would at least refer to the otrv4-standalone-mode inside the "Starting a conversation interactively" section.

I'll include something there.

Thanks!

[cobratbq]

While reading through the snippets, I find things are a lot clearer (and more explicit) already. Looks great. I'll follow up later when I'm back to investigating and implementing the Interactive DAKE state machine again. (I'm also curious if you can come up with a more elegant solution.)

[claucece]

Hey!

I'm also curious if you can come up with a more elegant solution.

Yeah.. I hope that ;) Let's see how it evolves.

[claucece]

Ok, I think this is solved now :)