otrv4 / otrv4 Goto Github PK
View Code? Open in Web Editor NEWOff-the-Record Messaging Protocol version 4. -This is a draft- This repository is a mirror of http://bugs.otr.im/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
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:
Do an overview of what that protocol description should contain
"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."
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:
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.
OTRv3 REQUIRE_ENCRYPTION
policy behaves like this:
If msgstate is
MSGSTATE_PLAINTEXT
:
IfREQUIRE_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 Q1
will 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 Q2
will 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).
This list will have the properties mentioned in the several sections of the spec and describe them within the context of this protocol.
"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."
[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?
"When using abbreviations or ideas that are introduced later in the
specification, either include forward references, or move the
definitions before their first use."
Including ed25519 or ed448.
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.
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:
Alice has multiple devices A1 and A2 that can be independently online/offline.
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
"Concepts referenced from the OTRv3 specification and
other documents should be included in the OTRv4 specification."
Including ed25519 or ed448
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
Depends on #4
We need to add a section to describe about the primitives, which should specify the schemes:
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.
This should also consider how to distinguish between legitimately adding new devices and an adversary intercepting the conversation.
We will first list ALL the pros and cons between RSDAKE&QuickSpawn and Spawn
The long term public keys are a requirement for the DAKE. In OTRv3, the public keys are exchanged as part of the AKE.
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.
This should describe the steps of the protocol at a high level and overall purpose of OTR.
(from email conversation)
In terms of what to do, from a quick think about it, this [is one] of the larger tasks.
Depends on #4
We need to add a section to describe about the primitives, which should specify the schemes:
g1
)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.
(from email conversation)
In terms of what to do, from a quick think about it, this [is one] of the larger tasks.
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.
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:
and can we do it in a way that keeps the forgeability of the surrounding stuff.
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.
and what the actual format will look like
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.