otrv4 / otrv4

Off-the-Record Messaging Protocol version 4. -This is a draft- This repository is a mirror of http://bugs.otr.im/otrv4/otrv4

OTRv4

Disclaimer

This protocol specification is a draft. It's currently under constant revision
by its team members or by its reviewers: Nik Unger or Ian Goldberg.

This is the protocol specification for Off-the-Record Messaging Protocol version 4.

Funding

The work made hare was partially 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's Issues

Create a good flow for the new protocol description

Describe SMP in terms of our new primitives

Alice requests a non-interactive conversation with Bob

Expected output: A textual description of the DAKE on the non-interactive setting.

The network model is assumed to be the same as OTRv3: "a network model which provides in-order delivery of messages, but that some messages may not get delivered at all (for example, if the user disconnects)". In addition, the network model provides in-order delivery of messages if the receiver is not online: the receiver will receive when it gets back online.

It must be presented in terms of the primitives (like OTRv3 explains in the "Authenticated Key Exchange (AKE)" section). It must not rely on any capability of the instant messaging service besides what is part of the network model.

Figure out whether we need a new fragmentation type or not

Figure out how to solve version rollback completely

The OTRv2 and v3 is doing version according to the query message ?OTRv3?, we should consider downgrade attack if MITM has capability to change this header.

Or, once we have otr4, we should also consider the deprecation of otr3/otr2 when we have otr5.

A version rollback may require key management for all versions, so that it can be able to handle different implementations AKE.

According to the TLS spec, we may also need statement rules like, implementation SHOULD/SHOULDNOT/MUST/MUSTNOT/CAN/SUGGESTED do something.

Explicit instructions for producing forged transcripts

"Ideally, any library that implements an OTRv4
API should be able to produce forged transcripts using the same
functions that are used to conduct honest conversations, and this design
should be strongly encouraged and guided by the specification."

Should we do the super-encryption?

and can we do it in a way that keeps the forgeability of the surrounding stuff.

Implement an "OTR toolkit" compatible with version 4

libotr provides an "OTR Messaging Toolkit". "This toolkit is useful for analyzing and/or forging OTR
messages."

It is a collection of command line apps:

• otr_parse
• otr_sesskeys
• otr_mackey
• otr_readforge
• otr_modify
• otr_remac

Identify the flaws in the OTRv3 description and decide how to rectify

(from email conversation)
In terms of what to do, from a quick think about it, this [is one] of the larger tasks.

Describe ROM-based Auth

Depends on #4

We need to add a section to describe about the primitives, which should specify the schemes:

• Auth use NIZKPK of the Knowledge of one secret Key among three public Keys.
• Choose a group and specify the generators (in Spawn should be the g1)
• Mention NIZKPK provided by Camenisch-Stadler notation
• Define Auth, which use the group and Hash
• Define Verify, which use the group and Hash
• Caution: the order of elements must not depend on the secret known

Figure out how to solve version rollback completely

Decide what official security properties we are aiming for and document those

Decide how the Long Term Public Keys will be exchanged

The long term public keys are a requirement for the DAKE. In OTRv3, the public keys are exchanged as part of the AKE.

Distributing public keys

In OTRv3, public keys are send to the other conversation participant in the Reveal Signature and Signature messages, which occurs in the last two steps of the AKE.

However, for the DAKE in OTRv4, both parties need each other´s long-term identity keys at the beginning of the AKE, in order to share keys and authenticate to each other.

How should we do this? If you don´t have the other person´s public key.

So our options are:

1. Add an extra step where each party will need to query a server for the other person´s public key before starting a conversation
2. Include the other party´s public key in ψ1 and ψ2 of the AKE. Not sure how this could break security properties.

Figure out the security level question

Including ed25519 or ed448.

Expiration of Long Term Keys

[For future consideration] As suggested by @tcz001, are we going to expire the long term keys? I see no expiration on previous versions. Is this for the implementor?

Figure out what else we need to transfer in the DAKE

and what the actual format will look like

Should we do superencryption, and can we do it in a way that keeps the forgeability of the surrounding stuff

Section for differences between otrv3 and v4

Describe SMP in terms of our new primitives

Instance tag descriptions, discussion whether v4 needs new instance tag types

Figure out the security level question

Including ed25519 or ed448

Figure out how much of the current OTR packet structure to change to get double ratcheting working

A note on prekeys pointing to a separate protocol description

Do an overview of what that protocol description should contain

Describe security and privacy properties

This list will have the properties mentioned in the several sections of the spec and describe them within the context of this protocol.

Define how the AKE should behave in a multi-device environment

Problem

The OTR AKE (SPAWN) requires the initiator to store prekeys in order to "verif[y] that g^i is a prekey that [the initiator has] previously sent and remains unused"[1]. An responder could send AKE messages to a different device than where the AKE was initiated.

The problem affects both the interactive and the non-interactive setting, because the network model does not specify any restriction regarding multi-device environments.

Background:

OTRv3 solves the multi-device problem using instance tags. Every message is sent with a number that identifies the sender device ID and the receiver device ID. Each device will ignore received messages containing a instance tag that does not match the device ID.

In the XMPP context, a user can be logged in to the same account on multiple devices - which poses the following problems to its implementation:

Problem Scenarios

Alice has multiple devices A1 and A2 that can be independently online/offline.

1. Alice generates pre-keys on device A1, but the reply is received on device A2 only.
   If she is logged in on device A2 (and device A1 is offline), for example.
   1. If device A2 does not support OTRv4, Alice will see a OTRv4 message (unreadable by humans) and she will never receive the encrypted data message on A1.
      This is not solved by OTRv3, and may not be solvable by us unless we use a XMPP-specific approach.
   2. If device A2 supports OTRv4, the AKE will fail (it wont be able to verify g^i is a pre-key).
      This is solvable by using instance tags only, but this couples the pre-key with OTRv4 in the sense we need to store pre-keys together with instance tags. This would associate all pre-keys generated on the same device (revealing this information). Note that TextSecure does a similar thing by sending prekeys
      "within a JSON structure consisting of a keyID z, a prekey g^xa,i , and the long-term key g^a"[1].
      Note A1 is still not able to receive the message which is just lost. This is an existing issue in OTRv3 and seems to be fixed by OMEMO in a XMPP-specific way.
2. Alice generates pre-keys on device A1, and the reply is received on both devices.
   1. If device A2 does not support OTRv4, Alice will see a OTRv4 message (unreadable by humans) on A2 but she will be able to finish the AKE on A1 and will see the encrypted data.
      This is not solved by OTRv3, and may not be solvable by us unless we use a XMPP-specific approach.
   2. If device A2 supports OTRv4, the AKE will fail on A2 (it wont be able to verify g^i is a pre-key) but will succeed on A1.
      This can also be solved by using instance tags: A1 will succeed and A2 will ignore the message (because it has a different instance tag).
3. Alice generates pre-keys on device A1, and the reply is received on A1 only (even if A2 is online).
   There is no problem to solve here.
4. Alice generates pre-keys on device A1, and the reply is received on A2 only (even if A1 is online). SAME AS case (1).

Solutions Specific to XMPP:

The same problem happens on the interactive setting, because the way XMPP clients send responses in a multi-device environment is implementation specific (you can't control if the other client will reply using a JID that includes a resource identifier)[2].

For the interactive setting we could recommend XMPP clients to reply AKE messages using a "full JID", and for the non-interactive we would need to associate the ¨full JID¨ to the pre-key.

With this solution, conversations would be restricted to a single device.

1 - See: "How Secure is TextSecure?".
2 - https://stackoverflow.com/questions/5048092/xmpp-receive-messages-sent-to-different-resource

OTRv4 spec should be entirely self contained

"Concepts referenced from the OTRv3 specification and
other documents should be included in the OTRv4 specification."

Describe the crypto primitives being used and common terminology

Figure out how much of the current OTR packet structure to change to get axolotl style ratcheting working

• How to reveal MAC keys in the context of double ratcheting?

Bob receives an offline AKE message

Checking Group Elements

"All group elements received from another party should be checked to
ensure that they are in the correct group and that they are not the
identity element. This is pointed out at one point in the document, but
not in other places where this check must be performed."

Backward compatibility with libotr.

According to README, libotr entry point is defined in the proto.h.

We can decide to provide libotr4 as a drop-in replacement to libotr. Updating to OTRv4 would mean replacing proto.h with a compat/proto.h (from the reference implementation).

To do so, we need to implement the public API provided by libotr. We tried to enumerate everything that is "public" in this proto.h, but there's a lot. We need to define how much of this we really want to expose in the context of backward compatibility.

Figure out which DAKE to use

We will first list ALL the pros and cons between RSDAKE&QuickSpawn and Spawn

Figure out which DAKE to use

Investigate multi-device conversations

This should also consider how to distinguish between legitimately adding new devices and an adversary intercepting the conversation.

Create a good flow for the new protocol description

(from email conversation)
In terms of what to do, from a quick think about it, this [is one] of the larger tasks.

Describe the AKE to be used.

Figure out what else we need to transfer in the DAKE and what the actual format will look like

Define the network model

OTRv3 assumes a network model which provides in-order delivery of messages, but that some messages may not get delivered at all (for example, if the user disconnects). There may be an active attacker, who is allowed to perform a Denial of Service attack, but not to learn the contents of messages.[1]

This is required because the OTR has a "three step ratchet".

If we use double-ratcheting in OTRv4 we don't need "in-order delivery of messages" but we are unsure if the AKE will work without this assumption.

1 - Off-the-Record Messaging Protocol version 3

Figure out whether we need a new fragmentation type or not

Describe ROM-based DRE

Depends on #4

We need to add a section to describe about the primitives, which should specify the schemes:

• DRE use CramerShoup + NIZKPK of the Knowledge of plaintext equivalence.
• Choose a group and specify two generators
• Define DRGen, which use the group
• Mention NIZKPK provided by Camenisch-Stadler notation
• Define DREnc, which need a AEnc, Hash
• Define DRDec, which need a ADec, Hash

Fix the issue with starting multiple AKEs

OTRv3 REQUIRE_ENCRYPTION policy behaves like this:

If msgstate is MSGSTATE_PLAINTEXT:
If REQUIRE_ENCRYPTION is set:
Store the plaintext message for possible retransmission, and send a Query Message.

The consequence is:

Alice is in MSGSTATE_PLAINTEXT state and has REQUIRE_ENCRYPTION.
Alice wants to start an OTR conversation with Bob.
Alice sends hi - which is going to be stored for retransmission and a query message Q1will be sent.
Before the AKE initiated by Q1 finishes, Alice sends r u fine? - which is going to be stored for retransmission and a query message Q2will be sent.
Every subsequent message sent by Alice before the AKE finishes will cause Bob to restart the AKE.

This may be fixed by handling unexpected messages properly (like OTRv3 does) to ensure a consistent state for the AKE (even if multiple AKEs have been started).

Protocol High Level Overview

This should describe the steps of the protocol at a high level and overall purpose of OTR.

Fixing references to ideas and abbreviations

"When using abbreviations or ideas that are introduced later in the
specification, either include forward references, or move the
definitions before their first use."

A note on prekeys pointing to a separate protocol description

• Do an overview of what that protocol description should contain.

Identify the flaws in the OTRv3 description and decide how to rectify

Discuss about policies changes

OTRv3 specifies a few policies to describe how a client should behave in certain conditions:

ALLOW_V1
Allow version 1 of the OTR protocol to be used (in general this document will not address OTR protocol version 1; see previous protocol documents for these details).
ALLOW_V2
Allow version 2 of the OTR protocol to be used.
ALLOW_V3
Allow version 3 of the OTR protocol to be used.
REQUIRE_ENCRYPTION
Refuse to send unencrypted messages.
SEND_WHITESPACE_TAG
Advertise your support of OTR using the whitespace tag.
WHITESPACE_START_AKE
Start the OTR AKE when you receive a whitespace tag.
ERROR_START_AKE
Start the OTR AKE when you receive an OTR Error Message.

The addition of non-interactive key-exchange for OTRv4 may require changing the policies to address its implications, for example:

• "I want to not use non-interactive key-exchange at all" (because it weakens online repudiation)
• "I want to force encryption even if it may require using non-interactive key-exchange" (at the cost of online repudiation)

We may want to do this by adding extra policies or changing the semantics of existing policies.

Obviously, we also need to add ALLOW_V4 to the policies.

Double Ratchet & Revealing Mac Keys

Double ratcheting has weaker message forgeability properties than OTR.

See "Deniability" section of this paper: https://eprint.iacr.org/2014/904.pdf

We should investigate how to reveal MAC keys as part of the Double Ratcheting protocol @tcz001 has some good ideas.

Alice requests an interactive conversation with Bob

Expected output: A textual description of the DAKE on the interactive setting.

The network model is assumed to be the same as OTRv3: "a network model which provides in-order delivery of messages, but that some messages may not get delivered at all (for example, if the user disconnects)".

It must be presented in terms of the primitives (like OTRv3 explains in the "Authenticated Key Exchange (AKE)" section). It must not rely on any capability of the instant messaging service besides sending and receiving messages.

Decide what official security properties we are aiming for and document those