moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0364: Retab

This commit is contained in:
Sam Whited 2016-04-24 17:44:33 -05:00
parent 70561049c7
commit cefba6e02c
1 changed files with 280 additions and 267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

547
xep-0364.xml
View File

@ -1,291 +1,304 @@
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [ <!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'> <!ENTITY % ents SYSTEM 'xep.ent'>
%ents; %ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>Current Off-the-Record Messaging Usage</title> <title>Current Off-the-Record Messaging Usage</title>
<abstract> <abstract>
This document outlines the current usage of Off-the-Record messaging in This document outlines the current usage of Off-the-Record messaging in
XMPP, its drawbacks, its strengths, and recommendations for improving the XMPP, its drawbacks, its strengths, and recommendations for improving the
end user experience. end user experience.
</abstract> </abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0364</number> <number>0364</number>
<status>Experimental</status> <status>Experimental</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname> <shortname>NOT_YET_ASSIGNED</shortname>
<author> <author>
<firstname>Sam</firstname> <firstname>Sam</firstname>
<surname>Whited</surname> <surname>Whited</surname>
<email>sam@samwhited.com</email> <email>sam@samwhited.com</email>
<jid>sam@samwhited.com</jid> <jid>sam@samwhited.com</jid>
</author> </author>
<revision> <revision>
<version>0.1</version> <version>0.2</version>
<date>2015-08-27</date> <date>2016-04-24</date>
<initials>XEP Editor (mam)</initials> <initials>ssw</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark> <remark>
</revision> <p>
<revision> Remove RFC 2119 language other than [NOT] RECOMMENDED; add session
<version>0.0.1</version> ending recommendations.
<date>2015-07-28</date> </p>
<initials>ssw</initials> </remark>
<remark><p>Initial draft.</p></remark> </revision>
</revision> <revision>
</header> <version>0.1</version>
<section1 topic='Introduction' anchor='intro'> <date>2015-08-27</date>
<p> <initials>XEP Editor (mam)</initials>
The Off-the-Record messaging protocol (OTR) was originally introduced in <remark><p>Initial published version approved by the XMPP Council.</p></remark>
the 2004 paper </revision>
<i><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'> <revision>
Off-the-Record Communication, or, Why Not To Use PGP <version>0.0.1</version>
</link></i> <date>2015-07-28</date>
<note> <initials>ssw</initials>
Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record <remark><p>Initial draft.</p></remark>
Communication, or, Why Not To Use PGP" </revision>
&lt;<link url='https://otr.cypherpunks.ca/otr-wpes.pdf'> </header>
https://otr.cypherpunks.ca/otr-wpes.pdf <section1 topic='Introduction' anchor='intro'>
</link>&gt; <p>
</note> The Off-the-Record messaging protocol (OTR) was originally introduced in
and has since become the de facto standard for performing end-to-end the 2004 paper
encryption in XMPP. OTR provides encryption, deniable authentication, <i><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
forward secrecy, and malleable encryption. Off-the-Record Communication, or, Why Not To Use PGP
</p> </link></i>
<p> <note>
The OTR protocol itself is currently described by the document: Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
<i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'> Communication, or, Why Not To Use PGP"
Off-the-Record Messaging Protocol version 3 &lt;<link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
</link></i> https://otr.cypherpunks.ca/otr-wpes.pdf
<note> </link>&gt;
"Off-the-Record Messaging Protocol version 3" </note>
&lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'> and has since become the de facto standard for performing end-to-end
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html encryption in XMPP. OTR provides encryption, deniable authentication,
</link>&gt; forward secrecy, and malleable encryption.
</note> </p>
and will not be redescribed here. Instead, this document aims to describe <p>
OTR's usage and best practices within XMPP. It is not intended to be a The OTR protocol itself is currently described by the document:
current standard, or technical specification, as better (albeit, newer and <i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
less well tested) methods of end-to-end encryption exist for XMPP. Off-the-Record Messaging Protocol version 3
</p> </link></i>
</section1> <note>
<section1 topic='Overview' anchor='overview'> "Off-the-Record Messaging Protocol version 3"
<p> &lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
Though this document will not focus on the OTR protocol itself, a brief https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
overview is warranted to better understand the protocols strengths and </link>&gt;
weaknesses. </note>
</p> and will not be redescribed here. Instead, this document aims to describe
<p> OTR's usage and best practices within XMPP. It is not intended to be a
OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function. current standard, or technical specification, as better (albeit, newer and
An OTR session can be held only between two parties, meaning that OTR is less well tested) methods of end-to-end encryption exist for XMPP.
incompatible with &xep0045;. It provides deniability in the form of </p>
malleable encryption (a third party may generate fake messages after the </section1>
session has ended). This means that if you were not a part of the original <section1 topic='Overview' anchor='overview'>
conversation, you cannot prove based on captured messages alone that a <p>
message from the conversation was actually sent by a given party. Unlike Though this document will not focus on the OTR protocol itself, a brief
PGP, OTR also provides forward secrecy; even if a session is recorded and overview is warranted to better understand the protocols strengths and
the primary key is compromised at a later date, the OTR messages will not weaknesses.
be able to be decrypted as each was encrypted with an ephemeral key </p>
exchanged with Diffie-Hellman key exchange with a 1536 bit modulus. <p>
</p> OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function.
</section1> An OTR session can be held only between two parties, meaning that OTR is
<section1 topic='Discovery'> incompatible with &xep0045; and &xep0369;. It provides deniability in the
<p> form of malleable encryption (a third party may generate fake messages
Clients that support the OTR protocol do not advertise it in any of the after the session has ended). This means that if you were not a part of
normal XMPP ways. Instead, OTR provides its own discovery mechanism. If a the original conversation, you cannot prove, based on captured messages
client wishes to indicate support for OTR they include a special whitespace alone, that a message from the conversation was actually sent by a given
tag in their messages. This tag can appear anywhere in the body of the party. Unlike PGP, OTR also provides forward secrecy; even if a session
message stanza, but it is most often found at the end. The OTR tag is recorded and the primary key is compromised at a later date, the OTR
comprises the following bytes: 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:
<example caption='OTR tag'> <example caption='OTR tag'>
\x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20 \x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
</example> </example>
and is followed by one or more of the following sequences to indicate the and is followed by one or more of the following sequences to indicate the
version of OTR which the client supports: version of OTR which the client supports:
<example caption='OTR tag version 1'> <example caption='OTR tag version 1'>
\x20\x09\x20\x09\x20\x20\x09\x20 \x20\x09\x20\x09\x20\x20\x09\x20
</example> </example>
Note that this version 1 tag must come before other version tags for Note that this version 1 tag must come before other version tags for
compatibility; it is, however, NOT RECOMMENDED to implement version 1 of compatibility; it is, however, NOT RECOMMENDED to implement version 1 of
the OTR protocol. the OTR protocol.
<example caption='OTR tag version 2'> <example caption='OTR tag version 2'>
\x20\x20\x09\x09\x20\x20\x09\x20 \x20\x20\x09\x09\x20\x20\x09\x20
</example> </example>
<example caption='OTR tag version 3'> <example caption='OTR tag version 3'>
\x20\x20\x09\x09\x20\x20\x09\x09 \x20\x20\x09\x09\x20\x20\x09\x09
</example> </example>
</p> </p>
<p> <p>
When a client sees this special string in the body of a message stanza it 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 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 to the user and allow the user to manually start a session. This is done
sending a message stanza containing an OTR query message in the body which by sending a message stanza containing an OTR query message in the body
indicates the supported versions of OTR. In XMPP these are most commonly which indicates the supported versions of OTR. In XMPP these are most
version 2 and version 3, which would be indicated by a message stanza which commonly version 2 and version 3, which would be indicated by a message
has a body that starts with the string: stanza which has a body that starts with the string:
<example caption='OTR query'> <example caption='OTR query'>
?OTR?v23? ?OTR?v23?
</example> </example>
</p> </p>
<p> <p>
Any message which begins with the afforementioned string (note that the Any message which begins with the afforementioned string (note that the
version number[s] may be different), postfixed with a payload should be version number[s] may be different), postfixed with a payload should be
decrypted as an OTR message. The initialization message should not contain decrypted as an OTR message. The initialization message should not contain
a payload, and should just be the initialization string by itself. a payload, and should just be the initialization string by itself.
</p> </p>
</section1> </section1>
<section1 topic='OTR Messages'> <section1 topic='OTR Messages'>
<section2 topic='Construction and Decoding'> <section2 topic='Construction and Decoding'>
<p> <p>
Some clients in the wild have been known to insert XML in the 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 &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 encrypted payloads which expand to unescaped XML, and treat it as plain
text. text.
</p> </p>
</section2> </section2>
<section2 topic='Routing'> <section2 topic='Routing'>
<p> <p>
XMPP is designed so that the client needs to know very little about where XMPP is designed so that the client needs to know very little about
and how a message will be routed. Generally, clients are encouraged to where and how a message will be routed. Generally, clients are
send messages to the bare JID and allow the server to route the messages encouraged to send messages to the bare JID and allow the server to
as it sees fit. However, OTR requires that messages be sent to a route the messages as it sees fit. However, OTR requires that messages
particular resource. Therefore clients SHOULD send OTR messages to a full be sent to a particular resource. Therefore clients should send OTR
JID, possibly allowing the user to determine which resource they wish to messages to a full JID, possibly allowing the user to determine which
start an encrypted session with. Furthermore, if a client receives a resource they wish to start an encrypted session with. Furthermore, if a
request to start an OTR session in a carboned message (due to a server client receives a request to start an OTR session in a carboned message
which does not support the aforementioned "private" directive, or a (due to a server which does not support the aforementioned "private"
client which does not set it), it SHOULD be silently ignored. directive, or a client which does not set it), it should be silently
</p> ignored.
</section2> </p>
<section2 topic='Processing Hints'> </section2>
<p> <section2 topic='Processing Hints'>
&xep0334; defines a set of hints for how messages should be handled by <p>
XMPP servers. These hints are not hard and fast rules, but suggestions &xep0334; defines a set of hints for how messages should be handled by
which the servers may or may not choose to follow. Best practice is to XMPP servers. These hints are not hard and fast rules, but suggestions
include the following hints on all OTR messages: which the servers may or may not choose to follow. Best practice is to
include the following hints on all OTR messages:
<code><![CDATA[ <code><![CDATA[
<no-copy xmlns="urn:xmpp:hints"/> <no-copy xmlns="urn:xmpp:hints"/>
<no-permanent-store xmlns="urn:xmpp:hints"/> <no-permanent-store xmlns="urn:xmpp:hints"/>
]]></code> ]]></code>
</p> </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[ <p>
<private xmlns="urn:xmpp:carbons:2"/> Similarly the "private" directive from &xep0280; should also be included
]]></code> 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):
<example caption='OTR message with processing hints'><![CDATA[ <code><![CDATA[
<message <private xmlns="urn:xmpp:carbons:2"/>
from='malvolio@stewardsguild.lit/countesshousehold' ]]></code>
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'> 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 xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
</example> </example>
</p> </p>
<p> <p>
The &REGISTRAR; maintains a registry of queries and key-value pairs for use The &REGISTRAR; maintains a registry of queries and key-value pairs for
in XMPP URIs at &QUERYTYPES;. As of the date this document was authored, use in XMPP URIs at &QUERYTYPES;. As of the date this document was
the 'otr-fingerprint' query string has not been formally defined and has authored, the 'otr-fingerprint' query string has not been formally defined
therefore is not officially recognized by the registrar. and has therefore is not officially recognized by the registrar.
</p> </p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>
<p> <p>
Thanks to Daniel Gultsch for his excellent Thanks to Daniel Gultsch for his excellent
<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'> <link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'>
article article
</link> </link>
<note> <note>
Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing
XMPP" XMPP"
&lt;<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'> &lt;<link url='https://github.com/siacs/Conversations/blob/development/docs/observations.md'>
https://github.com/siacs/Conversations/blob/development/docs/observations.md https://github.com/siacs/Conversations/blob/development/docs/observations.md
</link>&gt; </link>&gt;
</note> </note>
on the pitfalls of implementing OTR, and to Georg Lukas for his feedback. on the pitfalls of implementing OTR, and to Georg Lukas for his feedback.
</p> </p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p> <p>
While this document describes an existing protocol which is streamed over While this document describes an existing protocol which is streamed over
XMPP and therefore does not introduce any new security concerns itself, it XMPP and therefore does not introduce any new security concerns itself, it
is worth mentioning a few security issues with the underlying OTR protocol: is worth mentioning a few security issues with the underlying OTR
</p> protocol:
<p> </p>
Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial <p>
D-H exchange which sets up the encrypted channel is vulnerable to a Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial
man-in-the-middle attack. No sensitive information should be sent over the D-H exchange which sets up the encrypted channel is vulnerable to a
encrypted channel until mutual authentication has been performed man-in-the-middle attack. No sensitive information should be sent over the
inside the encrypted channel. encrypted channel until mutual authentication has been performed inside
</p> the encrypted channel.
<p> </p>
OTR makes use of the SHA-1 hash algorithm. While no practical attacks have <p>
been observed in SHA-1 at the time of this writing, theoretical attacks OTR makes use of the SHA-1 hash algorithm. While no practical attacks have
have been constructed, and attacks have been performed on hash functions been observed in SHA-1 at the time of this writing, theoretical attacks
that are similar to SHA-1. One cryptographer estimated that the cost have been constructed, and attacks have been performed on hash functions
of generating SHA-1 collisions was $2.77 million dollars in 2012, and would that are similar to SHA-1. One cryptographer estimated that the cost of
drop to $700,000 by 2015. generating SHA-1 collisions was $2.77 million dollars in 2012, and would
<note> drop to $700,000 by 2015.
Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?" <note>
&lt;<link url='https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html'> 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 &lt;<link url='https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html'>
</link>&gt; https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
</note>. </link>&gt;
This puts generating SHA-1 collisions well within the reach of governments, </note>.
malicious organizations, and even well-funded individuals. This puts generating SHA-1 collisions well within the reach of
</p> governments, malicious organizations, and even well-funded individuals.
</section1> </p>
<section1 topic='IANA Considerations' anchor='iana'> </section1>
<p> <section1 topic='IANA Considerations' anchor='iana'>
This document requires no interaction with the Internet Assigned Numbers <p>
Authority (IANA). This document requires no interaction with the Internet Assigned Numbers
</p> Authority (IANA).
</section1> </p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> </section1>
<p> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
No namespaces or parameters need to be registered with the XMPP Registrar <p>
as a result of this document. No namespaces or parameters need to be registered with the XMPP Registrar
</p> as a result of this document.
</section1> </p>
</section1>
</xep> </xep>