mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
362 lines
15 KiB
XML
362 lines
15 KiB
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>Deferred</status>
|
|
<type>Informational</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.3</version>
|
|
<date>2017-01-28</date>
|
|
<initials>egp</initials>
|
|
<remark><p>Add a suggestion to use XEP-0380.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2016-04-24</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<p>
|
|
Remove RFC 2119 language other than [NOT] RECOMMENDED, add session
|
|
ending recommendations, add delivery receipt recommendation.
|
|
</p>
|
|
</remark>
|
|
</revision>
|
|
<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
|
|
<em><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
|
|
Off-the-Record Communication, or, Why Not To Use PGP
|
|
</link></em>
|
|
<note>
|
|
Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
|
|
Communication, or, Why Not To Use PGP"
|
|
<<link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
|
|
https://otr.cypherpunks.ca/otr-wpes.pdf
|
|
</link>>
|
|
</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:
|
|
<em><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
|
|
Off-the-Record Messaging Protocol version 3
|
|
</link></em>
|
|
<note>
|
|
"Off-the-Record Messaging Protocol version 3"
|
|
<<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
|
|
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
|
|
</link>>
|
|
</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; 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.
|
|
</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:
|
|
</p>
|
|
|
|
<example caption='OTR tag'><![CDATA[
|
|
\x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
|
|
]]></example>
|
|
|
|
<p>
|
|
and is followed by one or more of the following sequences to indicate the
|
|
version of OTR which the client supports:
|
|
</p>
|
|
<example caption='OTR tag version 1'><![CDATA[
|
|
\x20\x09\x20\x09\x20\x20\x09\x20
|
|
]]></example>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
<example caption='OTR tag version 2'><![CDATA[
|
|
\x20\x20\x09\x09\x20\x20\x09\x20
|
|
]]></example>
|
|
<example caption='OTR tag version 3'><![CDATA[
|
|
\x20\x20\x09\x09\x20\x20\x09\x09
|
|
]]></example>
|
|
<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:
|
|
</p>
|
|
<example caption='OTR query'>?OTR?v23?</example>
|
|
<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
|
|
<body> 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:
|
|
</p>
|
|
<code><![CDATA[
|
|
<no-copy xmlns="urn:xmpp:hints"/>
|
|
<no-permanent-store xmlns="urn:xmpp:hints"/>
|
|
]]></code>
|
|
<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):
|
|
</p>
|
|
<code><![CDATA[<private xmlns="urn:xmpp:carbons:2"/>]]></code>
|
|
</section2>
|
|
<section2 topic='Explicit Message Encryption'>
|
|
<p>
|
|
&xep0380; defines a hint to let clients without OTR support know that
|
|
this message was encrypted, and display a friendly message instead of
|
|
the raw encrypted data. It is RECOMMENDED that the client adds this
|
|
hint alongside every encrypted message
|
|
</p>
|
|
<code><![CDATA[
|
|
<encryption xmlns="urn:xmpp:eme:0" namespace="urn:xmpp:otr:0"/>
|
|
]]></code>
|
|
<p>
|
|
All together, an example OTR message might look like this (with the
|
|
majority of the body stripped out for readability):
|
|
</p>
|
|
<example caption='OTR message with processing hints'><![CDATA[
|
|
<message from='malvolio@stewardsguild.lit/countesshousehold'
|
|
to='olivia@countess.lit/veiled'>
|
|
<body>?OTR?v23?...</body>
|
|
<encryption xmlns="urn:xmpp:eme:0" namespace="urn:xmpp:otr:0"/>
|
|
<no-copy xmlns="urn:xmpp:hints"/>
|
|
<no-permanent-store xmlns="urn:xmpp:hints"/>
|
|
<private xmlns="urn:xmpp:carbons:2"/>
|
|
</message>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='Delivery Receipts'>
|
|
<p>
|
|
If a client supports OTR and &xep0184; it is RECOMMENDED that the client
|
|
send a delivery receipt only after successfully decrypting an encrypted
|
|
message.
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='OTR Sessions'>
|
|
<section2 topic='Starting an OTR session'>
|
|
<p>
|
|
Most clients today provide options to automatically start an OTR
|
|
session, to manually construct a session at the users request, or to
|
|
always require the use of an OTR session even if the remote client does
|
|
not support OTR.
|
|
</p>
|
|
<p>
|
|
In the interest of user experience, it is NOT RECOMMENDED to start an
|
|
OTR session with a previously unseen resource or one for which we do not
|
|
have OTR keys cached without first discovering if the remote end
|
|
supports OTR using one of the mechanisms described in the "Discovery"
|
|
section of this document except in security critical contexts where user
|
|
experience is not a concern.
|
|
</p>
|
|
<p>
|
|
Instead, it is RECOMMENDED to always allow the user to manually start an
|
|
OTR session and to indicate that OTR is known to be available when OTR
|
|
support is discovered by any of the aforementioned mechanisms.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Ending an OTR session'>
|
|
<p>
|
|
It is RECOMMENDED that the lifetime of OTR sessions be limited to the
|
|
lifetime of the XMPP session in which the OTR session was established.
|
|
If a resource associated with either end of the OTR session goes offline
|
|
(a closing stream tag is received, or a fatal stream error occurs), it
|
|
is RECOMMENDED that the other end terminate the OTR session.
|
|
</p>
|
|
<p>
|
|
When an XMPP session that is hosting an OTR session ends, it is
|
|
RECOMMENDED that XMPP session be completely torn down before the
|
|
associated OTR session is ended. For instance, when receiving a closing
|
|
stream tag, clients should send their own closing stream tag (as
|
|
specified in &rfc6120;), close the underlying TCP connection (or
|
|
connections), and then terminate the OTR session in that order. This
|
|
prevents a race condition in some clients that attempt to automatically
|
|
establish an OTR session where the OTR session is torn down and then
|
|
re-established by an incomming message before the XMPP session can be
|
|
closed.
|
|
</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.
|
|
</p>
|
|
<example caption='OTR Fingerprint'><![CDATA[
|
|
xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
|
|
]]></example>
|
|
<p>
|
|
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.
|
|
</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"
|
|
<<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'>
|
|
https://github.com/siacs/Conversations/blob/development/docs/observations.md
|
|
</link>>
|
|
</note>
|
|
on the pitfalls of implementing OTR, and to Georg Lukas and Chris
|
|
Ballinger for their feedback and corrections.
|
|
</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?"
|
|
<<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>>
|
|
</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>
|