xeps/xep-0364.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Current Off-the-Record Messaging Usage</title>
	<abstract>
		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.
	</abstract>
  &LEGALNOTICE;
  <number>0364</number>
  <status>Experimental</status>
  <type>Informational</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  <author>
    <firstname>Sam</firstname>
    <surname>Whited</surname>
    <email>sam@samwhited.com</email>
    <jid>sam@samwhited.com</jid>
  </author>
  <revision>
    <version>0.1</version>
    <date>2015-08-27</date>
    <initials>XEP Editor (mam)</initials>
    <remark><p>Initial published version approved by the XMPP Council.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2015-07-28</date>
    <initials>ssw</initials>
    <remark><p>Initial draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
	<p>
		The Off-the-Record messaging protocol (OTR) was originally introduced in
		the 2004 paper
		<i><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
			Off-the-Record Communication, or, Why Not To Use PGP
		</link></i>
		<note>
			Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
			Communication, or, Why Not To Use PGP"
			&lt;<link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
				https://otr.cypherpunks.ca/otr-wpes.pdf
			</link>&gt;
		</note>
		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.
	</p>
	<p>
		The OTR protocol itself is currently described by the document:
		<i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
				Off-the-Record Messaging Protocol version 3
		</link></i>
		<note>
			"Off-the-Record Messaging Protocol version 3"
			&lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
				https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
			</link>&gt;
		</note>
		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.
	</p>
</section1>
<section1 topic='Overview' anchor='overview'>
	<p>
		Though this document will not focus on the OTR protocol itself, a brief
		overview is warranted to better understand the protocols strengths and
		weaknesses.
	</p>
	<p>
		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.
	</p>
</section1>
<section1 topic='Discovery'>
	<p>
		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:

		<example caption='OTR tag'>
\x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
		</example>

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

		<example caption='OTR tag version 1'>
\x20\x09\x20\x09\x20\x20\x09\x20
		</example>

	  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.

		<example caption='OTR tag version 2'>
\x20\x20\x09\x09\x20\x20\x09\x20
		</example>

		<example caption='OTR tag version 3'>
\x20\x20\x09\x09\x20\x20\x09\x09
		</example>
	</p>
	<p>
		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:

		<example caption='OTR query'>
?OTR?v23?
		</example>
	</p>
	<p>
		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.
	</p>
</section1>
<section1 topic='OTR Messages'>
	<section2 topic='Construction and Decoding'>
		<p>
			Some clients in the wild have been known to insert XML in the
			&lt;body&gt; node of a message. Clients that support OTR should tolerate
			encrypted payloads which expand to unescaped XML, and treat it as plain
			text.
		</p>
	</section2>
	<section2 topic='Routing'>
		<p>
			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.
		</p>
	</section2>
	<section2 topic='Processing Hints'>
		<p>
			&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:

	    <code><![CDATA[
	<no-copy xmlns="urn:xmpp:hints"/>
	<no-permanent-store xmlns="urn:xmpp:hints"/>
	    ]]></code>
		</p>
	
		<p>
			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):

	    <code><![CDATA[
	<private xmlns="urn:xmpp:carbons:2"/>
	    ]]></code>
	
			All together, an example OTR message might look like this (with the
			majority of the body stripped out for readability):

			<example caption='OTR message with processing hints'><![CDATA[
	<message
		  from='malvolio@stewardsguild.lit/countesshousehold'
		  to='olivia@countess.lit/veiled'>
		<body>?OTR?v23?...</body>
		<no-copy xmlns="urn:xmpp:hints"/>
		<no-permanent-store xmlns="urn:xmpp:hints"/>
		<private xmlns="urn:xmpp:carbons:2"/>
	</message>
			]]></example>
		</p>
	</section2>
</section1>
<section1 topic='Use in XMPP URIs'>
	<p>
		&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.

    <example caption='OTR Fingerprint'>
xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
    </example>
	</p>
	<p>
		The &REGISTRAR; 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.
	</p>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
	<p>
		Thanks to Daniel Gultsch for his excellent
		<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'>
			article
		</link>
		<note>
			Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing
			XMPP"
			&lt;<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'>
				https://github.com/siacs/Conversations/blob/development/docs/observations.md
			</link>&gt;
		</note>
		on the pitfalls of implementing OTR, and to Georg Lukas for his feedback.
	</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
	<p>
		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:
	</p>
	<p>
		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.
	</p>
	<p>
		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.
		<note>
			Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?"
			&lt;<link url='https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html'>
				https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
			</link>&gt;
		</note>.
		This puts generating SHA-1 collisions well within the reach of governments,
		malicious organizations, and even well-funded individuals.
	</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
	<p>
		This document requires no interaction with the Internet Assigned Numbers
		Authority (IANA).
	</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
	<p>
		No namespaces or parameters need to be registered with the XMPP Registrar
		as a result of this document.
	</p>
</section1>
</xep>