From c5cd20c877bbe27c35c942c9b3dee3e65acaca83 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Tue, 28 Jul 2015 22:05:33 -0500 Subject: [PATCH] Initial otr usage draft --- inbox/otr-info.xml | 291 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 291 insertions(+) create mode 100644 inbox/otr-info.xml diff --git a/inbox/otr-info.xml b/inbox/otr-info.xml new file mode 100644 index 00000000..ddc9750f --- /dev/null +++ b/inbox/otr-info.xml @@ -0,0 +1,291 @@ + + +%ents; +]> + + +
+ Current Off-the-Record Messaging Usage + + This document outlines the current usage of Off-the-Record messaging in + XMPP, its drawbacks, its strengths, and recommendations for improving the + end user experience. + + &LEGALNOTICE; + xxxx + ProtoXEP + Informational + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Sam + Whited + sam@samwhited.com + sam@samwhited.com + + + 0.0.1 + 2015-07-28 + ssw +

Initial draft.

 + +
+ +

+ 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;. 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 with 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: + + +\x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20 + + + and is followed by one or more of the following sequences to indicate the + version of OTR which the client supports: + + +\x20\x09\x20\x09\x20\x20\x09\x20 + + + 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. + + +\x20\x20\x09\x09\x20\x20\x09\x20 + + + +\x20\x20\x09\x09\x20\x20\x09\x09 + +

+

+ 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: + + +?OTR?v23? + +

+

+ 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. +

+ + + +

+ When sending a message encrypted with OTR, it is RECOMMENDED to encrypt + only the text node of the <body/> element (the message itself). + However, there are some clients in the wild which will encrypt the entire + contents of the <body/> element, including sub-nodes. Because of + this behavior, it is RECOMMENDED that clients decrypt and expand any OTR + messages inside of the body element before re-processing the element as a + whole. Clients that support OTR MUST tolerate encrypted payloads which + expand to XML, and those which expand to plain text messages. +

+ + +

+ XMPP is designed so that the client needs to know very little about where + and how a message will be routed. Generally, clients are encouraged to + send messages to the bare JID and allow the server to route the messages + as it sees fit. However, OTR requires that messages be sent to a + particular resource. Therefore clients SHOULD send OTR messages to a full + JID, possibly allowing the user to determine which resource they wish to + start an encrypted session with. Furthermore, if a client receives a + request to start an OTR session in a carboned message (due to a server + which does not support the aforementioned "private" directive, or a + client which does not set it), it SHOULD be silently ignored. +

+ + +

+ &xep0334; defines a set of hints for how messages should be handled by + XMPP servers. These hints are not hard and fast rules, but suggestions + which the servers may or may not choose to follow. Best practice is to + include the following hints on all OTR messages: + + + + ]]> +

+ +

+ Similarly the "private" directive from &xep0280; should also be included + to indicate that carbons are not necessary (since no other resource will + be able to read the message): + + + ]]> + + All together, an example OTR message might look like this (with the + majority of the body stripped out for readability): + + + ?OTR?v23?... + + + + + ]]> +

+ + + +

+ &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. + + +xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338 + +

+

+ 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 for his feedback. +

+ + +

+ 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 + and well funded criminal organizations. In this authors opinion, there are + no theoretical vulnerabilities, and SHA-1 should be treated as with extreme + caution. +

+ + +

+ 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. +

+ +