Queue messages to be sent over an encrypted state

[claucece]

Why

As we are currently implementing the revision number 2 of the OTRv4 specification, we need to include a consistent way of queueing plaintext messages to an encrypted state.

Reference

Please, refer to the "Sending a Data Message" and "Receiving plaintext with the whitespace tag" section of the OTRv4 spec. Please, check some of the TODOs over the library that refer to "queueing".

Tasks

• [ ] When "Sending a Data Message", if the state is not START or it is not the message attached to the Non-Interactive-Auth, queue the message for encrypting and sending it when the participant transitions to the ENCRYPTED_MESSAGES state.

Open questions

• Are policies allowed?

[juniorz]

• [ ] Also, when the DAKE finishes a data message needs to be sent, and the first message in the queue should be added to it, if there's any.

[juniorz]

The first task, mentions a part of the spec that does not make sense. On section "Receiving plaintext with the whitespace tag":

If the client has some policy dictating that 'OTR is always required' or that 'encryption is always required' (like REQUIRE_ENCRYPTION in OTRv3), and the tag offers OTR version 4 and version 4 is allowed: Queue the message for encrypting and sending it when the participant transitions to the ENCRYPTED_MESSAGES state.

Why are we gonna queue a received plaintext message? Unless it is referring to another message, this paragraph needs to be removed.

[claucece]

Why are we gonna queue a received plaintext message?

This is a recommendation sent in the email by Nik. It is basically the case of OTRv3, when a policy like REQUIRE_ENCRYPTION is set and you receive a plaintext, you queue this message to be encrypted and sent once the AKE finishes.. If it makes sense or not in the context for OTRv4 is to be seen :)

[juniorz]

But we have already received the plaintext message together with the whitespace tag, so this message can't be queued by who receives it (the section is "Receiving plaintext with the whitespace tag").

Maybe this was intended to be under the section "Whitespace Tags", which says when and how users generate and send whitespace tags.

[juniorz]

For me, this issue is about how REQUIRE_ENCRYPTION can be implemented by having a queue of pending messages.

Then I started to evaluate the first task in this issue. If this task is about the person who sends the whitespace tag, I can't see how queuing would work unless we send ONLY the whitespace tag and queue the plaintext that would accompany the tag. They can't start a AKE because they don't know which OTR version the other person supports.

This would make whitespace tags to act like "invisible" query messages. Of course, there is the risk of the queued message never arriving because there is no guarantee that the whitespace tag will ever be replied.

[juniorz]

If the task is about the person who receives the whitespace tag, I don't think there is anything that can be queued. The person needs to evaluate the received tag and maybe start an appropriate AKE if there's agreement on any version.

[claucece]

For context, check this here: https://github.com/otrv4/otrv4/issues/69

[juniorz]

I don't like the idea of queuing the message that contains the whitespace tag. A receiver who does not support any OTR version will receive multiple "blank" messages until they replies, and the sender will not know the messages did not arrive.

This could be fixed by sending all the queued messages in plaintext at the moment the sender decides to stop attaching whitespace tags (the moment they receive the first plaintext message back), but there would need to be separate queues for messages stored while the AKE is in progress (which should never be sent on plaintext) from messages stored while the whitespace tag is waiting for a response.

[claucece]

Oh, I see.. it was very badly written.. so the idea is when you receive a plaintext with the whitespace tag, as a receiver you can discard the plaintext but ask the sender to queue it for resend with encryption...

[claucece]

I'll repahrase on the spec, but it was basically:

When "Receiving plaintext with the whitespace tag", if the client has some policy dictating that 'OTR is always required' or that 'encryption is always required' (like REQUIRE_ENCRYPTION in OTRv3), and the tag offers OTR version 4 and version 4 is allowed, discard the plaintext but ask the sender to queue the message for encrypting and sending it when he/she transitions to the ENCRYPTED_MESSAGES state.

makes more sense? @juniorz

[claucece]

I guess this is also part of this issue: https://github.com/otrv4/libotr-ng/issues/54

This is something I was wanting to discuss, should be have some policies? @olabini

[juniorz]

Regarding otrv4/otrv4#69, I don't think I understand the goal. Why having the message resent if confidentiality is already lost for that message?

Regardless of the goal, this specific task needs further investigation since it has nothing to do with the queuing itself. I don't know how this "resend" request could be done with what we currently have in the protocol.

The proposed alternative of using the received message (including the whitespace tag) in the phi parameter brings the challenge of letting the initial sender's protocol know what phi needs to be - unless we are talking about requiring every DAKE started from a whitespace tag to include the original message in phi (and not only those which the receiver has REQUIRE_ENCRYPTION.

Can we remove "queuing" from this part of the spec, and discuss if this should be a feature in another issue? Even if this feature is already decided, I would prefer having this separate from queuing messages.

[claucece]

The proposed alternative of using the received message (including the whitespace tag) in the phi parameter brings the challenge of letting the initial sender's protocol know what phi needs to be - unless we are talking about requiring every DAKE started from a whitespace tag to include the original message in phi (and not only those which the receiver has REQUIRE_ENCRYPTION.

Yeah, we already decided against the phi thing.

Can we remove "queuing" from this part of the spec, and discuss if this should be a feature in another issue? Even if this feature is already decided, I would prefer having this separate from queuing messages.

Yes, we have issue #54 for that. I'll remove it from here. Thanks!

[juniorz]

discard the plaintext but ask the sender to queue the message for encrypting and sending

I still don't think queuing is what should be done here. We just want to store this particular message + whitespace tag that originated the DAKE, so it can be resent or used in phi.

I am happy with having this as part of #54.

[juniorz]

It seems this can be done completely at the plugin side by using the gone_secure callback to call otrng_send() for every pending (queued) message.

The plugin can also decide when to queue messages by asking the appropriate protocol for its encryption state.

We can do this as an issue for the plugin.