Initial draft of OTR disco

inbox/otrdisco.xml

@@ -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>