Initial draft of OTR disco

This commit is contained in:
Sam Whited 2015-08-29 15:03:50 -05:00 committed by Matthew A. Miller
parent b3725e2cf9
commit 81cefd2e88
1 changed files with 107 additions and 0 deletions

107
inbox/otrdisco.xml Normal file
View File

@ -0,0 +1,107 @@
<?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>OTR Discovery</title>
<abstract>
This document provides a mechanism by which OTR encryption support can be
discovered in XMPP, without relying on OTRs protocol agnostic discovery
mechanism.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</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-08-29</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) is widely layered on top of
XMPP to provide end-to-end encryption. Current use of the protocol is
described in &xep0364;. OTR provides its own discovery mechanism in which
it sends messages with special whitespace characters to indicate support.
While this works when initializing a session, there is no way to query a
client for support and to know in advance that a particular version of
OTR is supported. This XEP provides a mechanism for discovering OTR
support at the XMPP level. This specification aims to solve that by
providing an in-band mechanism for discovering OTR support in XMPP.
</p>
<p>
It should be noted that newer, more secure encryption protocols exist for
XMPP, and that new implementations of OTR are discouraged. This protocol
is primarily intended to solve issues with existing implementations of
OTR.
</p>
</section1>
<section1 topic='Discovering support' anchor='disco'>
<p>
If an entity supports OTR it MUST advertise the fact by returning a
feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030;
information request. It MUST also include '&lt;version&gt;' elements for
each version of the OTR protocol that is supported. Eg. an entity which
supports OTR versions 2 and 3 might include the following feature in its
disco info list:
<example caption='Disco response'><![CDATA[
<feature var='urn:xmpp:otr:0'>
<version>2</version>
<version>3</version>
</feature>
]]></example>
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>
Because OTR support is advertised outside of any end-to-end encrypted
stream, it may be subject to downgrade attacks (eg. the server operator
may remove one or more versions of OTR from the list).
</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>This specification defines the following XML namespaces:</p>
<ul>
<li>urn:xmpp:otr:0</li>
</ul>
<p>
The &REGISTRAR; shall include the foregoing namespaces in its disco
features registry as defined in &xep0030;.
<code caption='Registry Submission'><![CDATA[
<var>
<name>urn:xmpp:otr:0</name>
<desc>Indicates support for Off-the-Record Messaging (OTR)</desc>
<doc>XEP-xxxx</doc>
</var>
]]></code>
</p>
</section1>
</xep>