otrv4 / otrv4-client-imp-recommendations Goto Github PK

2.0 7.0 0.0 12 KB

Recommendations for clients implementing OTRv4. This is a mirror of https://bugs.otr.im/otrv4/otrv4-client-imp-recommendations

otr otrv4 deniability

otrv4-client-imp-recommendations's Introduction

OTRv4 recommendations for implementations

Recommendations for clients implementing OTRv4 protocol.

Funding

The work made hare was supported by the NlNet Foundation. Find information here.

Licensing and Use

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

The OTR team does not review implementations or specify which ones are compliant are not. Software implementers are free to implement this specification in any way they choose - under limitations of software licenses if using existing software.

otrv4-client-imp-recommendations's People

Contributors

Stargazers

Watchers

otrv4-client-imp-recommendations's Issues

How to make OTRv3 and OTRv4 work together

Handle delayed messages

We should recommend how to handle delayed messages in this situations:

Starting an online conversation after an offline one
Starting an offline conversation after an online one
Receiving a new Indetity message in ENCRYPTED_MESSAGES state.

We should also clarify how long the skipped_MKenc live in this situations.

See otrv4/otrv4#195 and otrv4/otrv4#215 for reference.

Define different test cases for the double ratchet algorithm

Allow conversion of OTRv4 decrypted plaintext into an specific format

See:

otrv4/pidgin-otrng#103

For this, this will help:

There is a callback that is made immediately before a message is encrypted and immediately after a message is decrypted. This callback can tweak the plaintext message as needed. For example, this could allow an application to convert formatting on a message if this would normally be done on the plaintext by some other entity while the message is in transit.

How the extra symmetric key can work

Handling the receive of TLV type 1 Disconnected

In previous OTR versions, receiving a disconnected TLV would put the
state machine into a "FINISHED" state. A client in this state would
refuse to send new messages from the user until the user explicitly
indicated that they understood the conversation was over.

The rationale was to prevent the following scenario:

Alice's client sends a disconnected TLV to Bob's client
Bob types a secret message into his client's textbox and begins to move his hand toward the "send" button
Bob's client receives the disconnected TLV and enters an "unencrypted" state
Bob presses the "send" button
Bob's client sends an unencrypted message that Bob intended to be sent securely

Previous OTR clients handled this situation by refusing to send Bob's message until he indicated that he understood the encrypted conversation was over, and then re-sent the message (or not). There are other UX choices that can be made here, but they must prevent this accidental leakage scenario.

Advice on processing chat history containing OTR transcript

Some networks allow receiving historic conversation content. Such message dumps may include a (in)complete OTR transcript, from query tag to end-of-session. In case a client is aware that this concerns historic chat messages, we may want to advise skipping processing of these messages altogether - or special treatment.

For example, IRCv3's chat history extension describes how one could receive a batch that is a complete conversation. XMPP seems to have something similar, although I'm not fully aware of XMPP features.

Consider the following issues:

processing historic messages will result in failing OTR sessions, hence not desirable.
not processing messages at all, will result in OTR-encoded "message spam" in the client chat window.

How to handle instance tags

Recommend how to generate the forging key and store it's secret part

Advice when verification of fingerprints has to be done

Define that every time that a long-term public key changes, a verification has to happen.

Better define how phi looks for different clients

Distinguish between Client Profile and fields relevant only to the signed payload

It may be useful to make a distinction between the data that is significant as part of the ClientProfile and the data that is important for the signed profile "payload". Most fields are relevant to the profile, but it seems to me that the Client Profile Expiration is only really useful for the signed payload.

When handling data in the client, one can internally manage the data without the expiration date and only when a (renewed) signed profile is required do we need to add a timestamp that we can determine at that time.