mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-10 11:25:00 -05:00
292 lines
11 KiB
XML
292 lines
11 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>xxxx</number>
|
|
<status>ProtoXEP</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.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"
|
|
<<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:
|
|
<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"
|
|
<<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;. 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>
|
|
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.
|
|
</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 ®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 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?"
|
|
<<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
|
|
and well funded criminal organizations. In this authors opinion, there are
|
|
no theoretical vulnerabilities, and SHA-1 should be treated as with extreme
|
|
caution.
|
|
</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>
|