Implement ERROR_START_DAKE policy

otrv4 / libotr-ng

A new implementation of OTR with support for version 4. This is a mirror of https://bugs.otr.im/otrv4/libotr-ng

Other

43 stars 9 forks source link

Implement ERROR_START_DAKE policy #150

Closed olabini closed 5 years ago

olabini commented 6 years ago

This policy governs whether we should start a new DAKE when receiving a plaintext "?OTR Error" message. It's not clear if this should happen to ALL OTR errors received or only some - and whether there should be different policy flag for the different possible errors. This should be investigated. This policy/these policies should be possible to control through the UI as well.

claucece commented 6 years ago

It's not clear if this should happen to ALL OTR errors received or only some - and whether there should be different policy flag for the different possible errors. This should be investigated.

I guess, in OTRv3, it was for all.

claucece commented 5 years ago

So, for OTRv3, it was for all error messages. For OTRv4, though, it makes sense only for:

 ERROR_1: (the message is undecryptable)
    Unreadable message
  ERROR_2: (the message arrived in a state that is not encrypted messages)
    Not in private state message

These ones should probably not start a DAKE:

  ERROR_3: (you were unable to encrypt the message)
    Encryption error
  ERROR_4: (the instance tags do not correspond)
    Malformed message

claucece commented 5 years ago

Ok, so looking at this, it makes sense now:

 ERROR_1: (the message is undecryptable)
    Unreadable message
  ERROR_4: (the instance tags do not correspond)
    Malformed message

It does not make sense for

  ERROR_2: (the message arrived in a state that is not encrypted messages)
    Not in private state message

because we are not allowed to send query messages in ENCRYPTED STATE. Let's discuss on Monday.

claucece commented 5 years ago

Notice that we only have now:

  ERROR_1: (the message is undecryptable)
    Unreadable message
  ERROR_2: (the message arrived in a state that is not encrypted messages)
    Not in private state message
  ERROR_3: (the instance tags do not correspond)
    Malformed message

because we are not allowed to send query messages in ENCRYPTED STATE. Let's discuss on Monday.

The idea will be then that an user will send a TLV type 1 and then send a query message. But this still does not make sense:

Alice sends a data message as she is in ENCRYPTED STATE.
Bob, not in ENCRYPTED STATE, receives it and send a ERROR_2.
Alice receives ERROR_2, and sends a TLV type 1 and a query message.
Bob received the data message with TLV type 1 and is unable to decrypt (as it is not in ENCRYPTED STATE). He sends again a ERROR_2. This can be an infinite loop.

What do you think @olabini ?

olabini commented 5 years ago

Hmm yeah. It clearly doesn't make sense to send a TLV#1 on ERROR_2 - as you say, it will be an infinite loop. It might be better for Alice to shut down her encrypted state without sending TLV#1 and then send a query message.

claucece commented 5 years ago

Ok, this is basically done; but I wanted to document some things:

We can't send query messages in ENCRYPTED_STATE and using a TLV 1 + query message is not possible, so the session is locally forgotten and then the query message is sent.
With this error, we can't reveal the MAC key of the data message. Consider:

Alice sends a data message in 'ENCRYPTED_STATE'
Bob not in ENCRYPTED_STATE receives it and is unable to process. Sends 'ERROR_2'
Alice receives 'ERROR_2', locally ends the session and sends a query message

Note that the MAC key from the data message is not revealed, as MAC keys are revealed on the first DH ratchet message after receiving several messages. What we could do is maybe add that MAC key to the query message...

This is documentation for otrv4/otrv4-client-imp-recommendations#5