The Off-the-Record messaging protocol (OTR) was originally introduced in the 2004 paper Off-the-Record Communication, or, Why Not To Use PGP Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record Communication, or, Why Not To Use PGP" < https://otr.cypherpunks.ca/otr-wpes.pdf > and has since become the de facto standard for performing end-to-end encryption in XMPP. OTR provides encryption, deniable authentication, forward secrecy, and malleable encryption.

The OTR protocol itself is currently described by the document: Off-the-Record Messaging Protocol version 3 "Off-the-Record Messaging Protocol version 3" < https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html > and will not be redescribed here. Instead, this document aims to describe OTR's usage and best practices within XMPP. It is not intended to be a current standard, or technical specification, as better (albeit, newer and less well tested) methods of end-to-end encryption exist for XMPP.

Though this document will not focus on the OTR protocol itself, a brief overview is warranted to better understand the protocols strengths and weaknesses.

OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function. An OTR session can be held only between two parties, meaning that OTR is incompatible with &xep0045; and &xep0369;. It provides deniability in the form of malleable encryption (a third party may generate fake messages after the session has ended). This means that if you were not a part of the original conversation, you cannot prove, based on captured messages alone, that a message from the conversation was actually sent by a given party. Unlike PGP, OTR also provides forward secrecy; even if a session is recorded and the primary key is compromised at a later date, the OTR messages will not be able to be decrypted as each was encrypted with an ephemeral key exchanged via Diffie-Hellman key exchange with a 1536 bit modulus.

Clients that support the OTR protocol do not advertise it in any of the normal XMPP ways. Instead, OTR provides its own discovery mechanism. If a client wishes to indicate support for OTR they include a special whitespace tag in their messages. This tag can appear anywhere in the body of the message stanza, but it is most often found at the end. The OTR tag comprises the following bytes:

and is followed by one or more of the following sequences to indicate the version of OTR which the client supports:

Note that this version 1 tag must come before other version tags for compatibility; it is, however, NOT RECOMMENDED to implement version 1 of the OTR protocol.

When a client sees this special string in the body of a message stanza it may choose to start an OTR session immediately, or merely indicate support to the user and allow the user to manually start a session. This is done by sending a message stanza containing an OTR query message in the body which indicates the supported versions of OTR. In XMPP these are most commonly version 2 and version 3, which would be indicated by a message stanza which has a body that starts with the string:

Any message which begins with the afforementioned string (note that the version number[s] may be different), postfixed with a payload should be decrypted as an OTR message. The initialization message should not contain a payload, and should just be the initialization string by itself.

&rfc5122; defines a Uniform Resource Identifier (URI) and Internationalized Resource Identifier (IRI) scheme for XMPP entities, and &xep0147; defines various query components for use with XMPP URI's. When an entity has an associated OTR fingerprint it's URI is often formed with "otr-fingerprint" in the query string. Eg.

The ®ISTRAR; maintains a registry of queries and key-value pairs for use in XMPP URIs at &QUERYTYPES;. As of the date this document was authored, the 'otr-fingerprint' query string has not been formally defined and has therefore is not officially recognized by the registrar.

Thanks to Daniel Gultsch for his excellent article Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing XMPP" < https://github.com/siacs/Conversations/blob/development/docs/observations.md > on the pitfalls of implementing OTR, and to Georg Lukas and Chris Ballinger for their feedback and corrections.

While this document describes an existing protocol which is streamed over XMPP and therefore does not introduce any new security concerns itself, it is worth mentioning a few security issues with the underlying OTR protocol:

Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial D-H exchange which sets up the encrypted channel is vulnerable to a man-in-the-middle attack. No sensitive information should be sent over the encrypted channel until mutual authentication has been performed inside the encrypted channel.

OTR makes use of the SHA-1 hash algorithm. While no practical attacks have been observed in SHA-1 at the time of this writing, theoretical attacks have been constructed, and attacks have been performed on hash functions that are similar to SHA-1. One cryptographer estimated that the cost of generating SHA-1 collisions was $2.77 million dollars in 2012, and would drop to $700,000 by 2015. Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?" < https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > . This puts generating SHA-1 collisions well within the reach of governments, malicious organizations, and even well-funded individuals.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document.