No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0364.xml 15KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>Current Off-the-Record Messaging Usage</title>
  10. <abstract>
  11. This document outlines the current usage of Off-the-Record messaging in
  12. XMPP, its drawbacks, its strengths, and recommendations for improving the
  13. end user experience.
  14. </abstract>
  16. <number>0364</number>
  17. <status>Deferred</status>
  18. <type>Informational</type>
  19. <sig>Standards</sig>
  20. <approver>Council</approver>
  21. <dependencies>
  22. <spec>XMPP Core</spec>
  23. </dependencies>
  24. <supersedes/>
  25. <supersededby/>
  26. <shortname>NOT_YET_ASSIGNED</shortname>
  27. &sam;
  28. <revision>
  29. <version>0.3</version>
  30. <date>2017-01-28</date>
  31. <initials>egp</initials>
  32. <remark><p>Add a suggestion to use XEP-0380.</p></remark>
  33. </revision>
  34. <revision>
  35. <version>0.2</version>
  36. <date>2016-04-24</date>
  37. <initials>ssw</initials>
  38. <remark>
  39. <p>
  40. Remove RFC 2119 language other than [NOT] RECOMMENDED, add session
  41. ending recommendations, add delivery receipt recommendation.
  42. </p>
  43. </remark>
  44. </revision>
  45. <revision>
  46. <version>0.1</version>
  47. <date>2015-08-27</date>
  48. <initials>XEP Editor (mam)</initials>
  49. <remark><p>Initial published version approved by the XMPP Council.</p></remark>
  50. </revision>
  51. <revision>
  52. <version>0.0.1</version>
  53. <date>2015-07-28</date>
  54. <initials>ssw</initials>
  55. <remark><p>Initial draft.</p></remark>
  56. </revision>
  57. </header>
  58. <section1 topic='Introduction' anchor='intro'>
  59. <p>
  60. The Off-the-Record messaging protocol (OTR) was originally introduced in
  61. the 2004 paper
  62. <em><link url=''>
  63. Off-the-Record Communication, or, Why Not To Use PGP
  64. </link></em>
  65. <note>
  66. Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
  67. Communication, or, Why Not To Use PGP"
  68. &lt;<link url=''>
  70. </link>&gt;
  71. </note>
  72. and has since become the de facto standard for performing end-to-end
  73. encryption in XMPP. OTR provides encryption, deniable authentication,
  74. forward secrecy, and malleable encryption.
  75. </p>
  76. <p>
  77. The OTR protocol itself is currently described by the document:
  78. <em><link url=''>
  79. Off-the-Record Messaging Protocol version 3
  80. </link></em>
  81. <note>
  82. "Off-the-Record Messaging Protocol version 3"
  83. &lt;<link url=''>
  85. </link>&gt;
  86. </note>
  87. and will not be redescribed here. Instead, this document aims to describe
  88. OTR's usage and best practices within XMPP. It is not intended to be a
  89. current standard, or technical specification, as better (albeit, newer and
  90. less well tested) methods of end-to-end encryption exist for XMPP.
  91. </p>
  92. </section1>
  93. <section1 topic='Overview' anchor='overview'>
  94. <p>
  95. Though this document will not focus on the OTR protocol itself, a brief
  96. overview is warranted to better understand the protocols strengths and
  97. weaknesses.
  98. </p>
  99. <p>
  100. OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function.
  101. An OTR session can be held only between two parties, meaning that OTR is
  102. incompatible with &xep0045; and &xep0369;. It provides deniability in the
  103. form of malleable encryption (a third party may generate fake messages
  104. after the session has ended). This means that if you were not a part of
  105. the original conversation, you cannot prove, based on captured messages
  106. alone, that a message from the conversation was actually sent by a given
  107. party. Unlike PGP, OTR also provides forward secrecy; even if a session
  108. is recorded and the primary key is compromised at a later date, the OTR
  109. messages will not be able to be decrypted as each was encrypted with an
  110. ephemeral key exchanged via Diffie-Hellman key exchange with a 1536 bit
  111. modulus.
  112. </p>
  113. </section1>
  114. <section1 topic='Discovery'>
  115. <p>
  116. Clients that support the OTR protocol do not advertise it in any of the
  117. normal XMPP ways. Instead, OTR provides its own discovery mechanism. If a
  118. client wishes to indicate support for OTR they include a special
  119. whitespace tag in their messages. This tag can appear anywhere in the body
  120. of the message stanza, but it is most often found at the end. The OTR tag
  121. comprises the following bytes:
  122. </p>
  123. <example caption='OTR tag'><![CDATA[
  124. \x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
  125. ]]></example>
  126. <p>
  127. and is followed by one or more of the following sequences to indicate the
  128. version of OTR which the client supports:
  129. </p>
  130. <example caption='OTR tag version 1'><![CDATA[
  131. \x20\x09\x20\x09\x20\x20\x09\x20
  132. ]]></example>
  133. <p>
  134. Note that this version 1 tag must come before other version tags for
  135. compatibility; it is, however, NOT RECOMMENDED to implement version 1 of
  136. the OTR protocol.
  137. </p>
  138. <example caption='OTR tag version 2'><![CDATA[
  139. \x20\x20\x09\x09\x20\x20\x09\x20
  140. ]]></example>
  141. <example caption='OTR tag version 3'><![CDATA[
  142. \x20\x20\x09\x09\x20\x20\x09\x09
  143. ]]></example>
  144. <p>
  145. When a client sees this special string in the body of a message stanza it
  146. may choose to start an OTR session immediately, or merely indicate support
  147. to the user and allow the user to manually start a session. This is done
  148. by sending a message stanza containing an OTR query message in the body
  149. which indicates the supported versions of OTR. In XMPP these are most
  150. commonly version 2 and version 3, which would be indicated by a message
  151. stanza which has a body that starts with the string:
  152. </p>
  153. <example caption='OTR query'>?OTR?v23?</example>
  154. <p>
  155. Any message which begins with the afforementioned string (note that the
  156. version number[s] may be different), postfixed with a payload should be
  157. decrypted as an OTR message. The initialization message should not contain
  158. a payload, and should just be the initialization string by itself.
  159. </p>
  160. </section1>
  161. <section1 topic='OTR Messages'>
  162. <section2 topic='Construction and Decoding'>
  163. <p>
  164. Some clients in the wild have been known to insert XML in the
  165. &lt;body&gt; node of a message. Clients that support OTR should tolerate
  166. encrypted payloads which expand to unescaped XML, and treat it as plain
  167. text.
  168. </p>
  169. </section2>
  170. <section2 topic='Routing'>
  171. <p>
  172. XMPP is designed so that the client needs to know very little about
  173. where and how a message will be routed. Generally, clients are
  174. encouraged to send messages to the bare JID and allow the server to
  175. route the messages as it sees fit. However, OTR requires that messages
  176. be sent to a particular resource. Therefore clients should send OTR
  177. messages to a full JID, possibly allowing the user to determine which
  178. resource they wish to start an encrypted session with. Furthermore, if a
  179. client receives a request to start an OTR session in a carboned message
  180. (due to a server which does not support the aforementioned "private"
  181. directive, or a client which does not set it), it should be silently
  182. ignored.
  183. </p>
  184. </section2>
  185. <section2 topic='Processing Hints'>
  186. <p>
  187. &xep0334; defines a set of hints for how messages should be handled by
  188. XMPP servers. These hints are not hard and fast rules, but suggestions
  189. which the servers may or may not choose to follow. Best practice is to
  190. include the following hints on all OTR messages:
  191. </p>
  192. <code><![CDATA[
  193. <no-copy xmlns="urn:xmpp:hints"/>
  194. <no-permanent-store xmlns="urn:xmpp:hints"/>
  195. ]]></code>
  196. <p>
  197. Similarly the "private" directive from &xep0280; should also be included
  198. to indicate that carbons are not necessary (since no other resource will
  199. be able to read the message):
  200. </p>
  201. <code><![CDATA[<private xmlns="urn:xmpp:carbons:2"/>]]></code>
  202. </section2>
  203. <section2 topic='Explicit Message Encryption'>
  204. <p>
  205. &xep0380; defines a hint to let clients without OTR support know that
  206. this message was encrypted, and display a friendly message instead of
  207. the raw encrypted data. It is RECOMMENDED that the client adds this
  208. hint alongside every encrypted message
  209. </p>
  210. <code><![CDATA[
  211. <encryption xmlns="urn:xmpp:eme:0" namespace="urn:xmpp:otr:0"/>
  212. ]]></code>
  213. <p>
  214. All together, an example OTR message might look like this (with the
  215. majority of the body stripped out for readability):
  216. </p>
  217. <example caption='OTR message with processing hints'><![CDATA[
  218. <message from='malvolio@stewardsguild.lit/countesshousehold'
  219. to='olivia@countess.lit/veiled'>
  220. <body>?OTR?v23?...</body>
  221. <encryption xmlns="urn:xmpp:eme:0" namespace="urn:xmpp:otr:0"/>
  222. <no-copy xmlns="urn:xmpp:hints"/>
  223. <no-permanent-store xmlns="urn:xmpp:hints"/>
  224. <private xmlns="urn:xmpp:carbons:2"/>
  225. </message>
  226. ]]></example>
  227. </section2>
  228. <section2 topic='Delivery Receipts'>
  229. <p>
  230. If a client supports OTR and &xep0184; it is RECOMMENDED that the client
  231. send a delivery receipt only after successfully decrypting an encrypted
  232. message.
  233. </p>
  234. </section2>
  235. </section1>
  236. <section1 topic='OTR Sessions'>
  237. <section2 topic='Starting an OTR session'>
  238. <p>
  239. Most clients today provide options to automatically start an OTR
  240. session, to manually construct a session at the users request, or to
  241. always require the use of an OTR session even if the remote client does
  242. not support OTR.
  243. </p>
  244. <p>
  245. In the interest of user experience, it is NOT RECOMMENDED to start an
  246. OTR session with a previously unseen resource or one for which we do not
  247. have OTR keys cached without first discovering if the remote end
  248. supports OTR using one of the mechanisms described in the "Discovery"
  249. section of this document except in security critical contexts where user
  250. experience is not a concern.
  251. </p>
  252. <p>
  253. Instead, it is RECOMMENDED to always allow the user to manually start an
  254. OTR session and to indicate that OTR is known to be available when OTR
  255. support is discovered by any of the aforementioned mechanisms.
  256. </p>
  257. </section2>
  258. <section2 topic='Ending an OTR session'>
  259. <p>
  260. It is RECOMMENDED that the lifetime of OTR sessions be limited to the
  261. lifetime of the XMPP session in which the OTR session was established.
  262. If a resource associated with either end of the OTR session goes offline
  263. (a closing stream tag is received, or a fatal stream error occurs), it
  264. is RECOMMENDED that the other end terminate the OTR session.
  265. </p>
  266. <p>
  267. When an XMPP session that is hosting an OTR session ends, it is
  268. RECOMMENDED that XMPP session be completely torn down before the
  269. associated OTR session is ended. For instance, when receiving a closing
  270. stream tag, clients should send their own closing stream tag (as
  271. specified in &rfc6120;), close the underlying TCP connection (or
  272. connections), and then terminate the OTR session in that order. This
  273. prevents a race condition in some clients that attempt to automatically
  274. establish an OTR session where the OTR session is torn down and then
  275. re-established by an incomming message before the XMPP session can be
  276. closed.
  277. </p>
  278. </section2>
  279. </section1>
  280. <section1 topic='Use in XMPP URIs'>
  281. <p>
  282. &rfc5122; defines a Uniform Resource Identifier (URI) and
  283. Internationalized Resource Identifier (IRI) scheme for XMPP entities, and
  284. &xep0147; defines various query components for use with XMPP URI's. When
  285. an entity has an associated OTR fingerprint it's URI is often formed with
  286. "otr-fingerprint" in the query string. Eg.
  287. </p>
  288. <example caption='OTR Fingerprint'><![CDATA[
  289. xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
  290. ]]></example>
  291. <p>
  292. The &REGISTRAR; maintains a registry of queries and key-value pairs for
  293. use in XMPP URIs at &QUERYTYPES;. As of the date this document was
  294. authored, the 'otr-fingerprint' query string has not been formally defined
  295. and has therefore is not officially recognized by the registrar.
  296. </p>
  297. </section1>
  298. <section1 topic='Acknowledgements' anchor='acks'>
  299. <p>
  300. Thanks to Daniel Gultsch for his excellent
  301. <link url=''>
  302. article
  303. </link>
  304. <note>
  305. Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing
  306. XMPP"
  307. &lt;<link url=''>
  309. </link>&gt;
  310. </note>
  311. on the pitfalls of implementing OTR, and to Georg Lukas and Chris
  312. Ballinger for their feedback and corrections.
  313. </p>
  314. </section1>
  315. <section1 topic='Security Considerations' anchor='security'>
  316. <p>
  317. While this document describes an existing protocol which is streamed over
  318. XMPP and therefore does not introduce any new security concerns itself, it
  319. is worth mentioning a few security issues with the underlying OTR
  320. protocol:
  321. </p>
  322. <p>
  323. Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial
  324. D-H exchange which sets up the encrypted channel is vulnerable to a
  325. man-in-the-middle attack. No sensitive information should be sent over the
  326. encrypted channel until mutual authentication has been performed inside
  327. the encrypted channel.
  328. </p>
  329. <p>
  330. OTR makes use of the SHA-1 hash algorithm. While no practical attacks have
  331. been observed in SHA-1 at the time of this writing, theoretical attacks
  332. have been constructed, and attacks have been performed on hash functions
  333. that are similar to SHA-1. One cryptographer estimated that the cost of
  334. generating SHA-1 collisions was $2.77 million dollars in 2012, and would
  335. drop to $700,000 by 2015.
  336. <note>
  337. Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?"
  338. &lt;<link url=''>
  340. </link>&gt;
  341. </note>.
  342. This puts generating SHA-1 collisions well within the reach of
  343. governments, malicious organizations, and even well-funded individuals.
  344. </p>
  345. </section1>
  346. <section1 topic='IANA Considerations' anchor='iana'>
  347. <p>
  348. This document requires no interaction with the Internet Assigned Numbers
  349. Authority (IANA).
  350. </p>
  351. </section1>
  352. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  353. <p>
  354. No namespaces or parameters need to be registered with the XMPP Registrar
  355. as a result of this document.
  356. </p>
  357. </section1>
  358. </xep>