XEP-0364: Retab

xep-0364.xml

@@ -1,11 +1,11 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
-  <!ENTITY % ents SYSTEM 'xep.ent'>
+<!ENTITY % ents SYSTEM 'xep.ent'>
 %ents;
 ]>
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
-<header>
+  <header>
     <title>Current Off-the-Record Messaging Usage</title>
     <abstract>
       This document outlines the current usage of Off-the-Record messaging in
@@ -30,6 +30,17 @@
       <email>sam@samwhited.com</email>
       <jid>sam@samwhited.com</jid>
     </author>
+    <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.
+        </p>
+      </remark>
+    </revision>
     <revision>
       <version>0.1</version>
       <date>2015-08-27</date>
@@ -42,8 +53,8 @@
       <initials>ssw</initials>
       <remark><p>Initial draft.</p></remark>
     </revision>
-</header>
+  </header>
-<section1 topic='Introduction' anchor='intro'>
+  <section1 topic='Introduction' anchor='intro'>
     <p>
       The Off-the-Record messaging protocol (OTR) was originally introduced in
       the 2004 paper
@@ -77,8 +88,8 @@
       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>
-<section1 topic='Overview' anchor='overview'>
+  <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
@@ -87,24 +98,25 @@
     <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
+      incompatible with &xep0045; and &xep0369;. It provides deniability in the
-		malleable encryption (a third party may generate fake messages after the
+      form of malleable encryption (a third party may generate fake messages
-		session has ended). This means that if you were not a part of the original
+      after the session has ended). This means that if you were not a part of
-		conversation, you cannot prove based on captured messages alone that a
+      the original conversation, you cannot prove, based on captured messages
-		message from the conversation was actually sent by a given party. Unlike
+      alone, that a message from the conversation was actually sent by a given
-		PGP, OTR also provides forward secrecy; even if a session is recorded and
+      party.  Unlike PGP, OTR also provides forward secrecy; even if a session
-		the primary key is compromised at a later date, the OTR messages will not
+      is recorded and the primary key is compromised at a later date, the OTR
-		be able to be decrypted as each was encrypted with an ephemeral key
+      messages will not be able to be decrypted as each was encrypted with an
-		exchanged with Diffie-Hellman key exchange with a 1536 bit modulus.
+      ephemeral key exchanged via Diffie-Hellman key exchange with a 1536 bit
+      modulus.
     </p>
-</section1>
+  </section1>
-<section1 topic='Discovery'>
+  <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
+      client wishes to indicate support for OTR they include a special
-		tag in their messages. This tag can appear anywhere in the body of the
+      whitespace tag in their messages. This tag can appear anywhere in the body
-		message stanza, but it is most often found at the end. The OTR tag
+      of the message stanza, but it is most often found at the end. The OTR tag
       comprises the following bytes:
 
       <example caption='OTR tag'>
@@ -133,11 +145,11 @@
     <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
+      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'>
 ?OTR?v23?
@@ -149,8 +161,8 @@
       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>
-<section1 topic='OTR Messages'>
+  <section1 topic='OTR Messages'>
     <section2 topic='Construction and Decoding'>
       <p>
         Some clients in the wild have been known to insert XML in the
@@ -161,16 +173,17 @@
     </section2>
     <section2 topic='Routing'>
       <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
+        ignored.
       </p>
     </section2>
     <section2 topic='Processing Hints'>
@@ -181,8 +194,8 @@
         include the following hints on all OTR messages:
 
         <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>
       </p>
 
@@ -192,45 +205,44 @@
         be able to read the message):
 
         <code><![CDATA[
-	<private xmlns="urn:xmpp:carbons:2"/>
+<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
+<message from='malvolio@stewardsguild.lit/countesshousehold'
-		  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>
+</message>
           ]]></example>
       </p>
     </section2>
-</section1>
+  </section1>
-<section1 topic='Use in XMPP URIs'>
+  <section1 topic='Use in XMPP URIs'>
     <p>
-		&rfc5122; defines a Uniform Resource Identifier (URI) and Internationalized
+      &rfc5122; defines a Uniform Resource Identifier (URI) and
-		Resource Identifier (IRI) scheme for XMPP entities, and &xep0147; defines
+      Internationalized Resource Identifier (IRI) scheme for XMPP entities, and
-		various query components for use with XMPP URI's. When an entity has an
+      &xep0147; defines various query components for use with XMPP URI's. When
-		associated OTR fingerprint it's URI is often formed with "otr-fingerprint"
+      an entity has an associated OTR fingerprint it's URI is often formed with
-		in the query string. Eg.
+      "otr-fingerprint" in the query string. Eg.
 
       <example caption='OTR Fingerprint'>
 xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
       </example>
     </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>
-</section1>
+  </section1>
-<section1 topic='Acknowledgements' anchor='acks'>
+  <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'>
@@ -245,26 +257,27 @@ xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
       </note>
       on the pitfalls of implementing OTR, and to Georg Lukas for his feedback.
     </p>
-</section1>
+  </section1>
-<section1 topic='Security Considerations' anchor='security'>
+  <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:
+      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
+      encrypted channel until mutual authentication has been performed inside
-		inside the encrypted channel.
+      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
+      that are similar to SHA-1. One cryptographer estimated that the cost of
-		of generating SHA-1 collisions was $2.77 million dollars in 2012, and would
+      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?"
@@ -272,20 +285,20 @@ xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
           https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
         </link>&gt;
       </note>.
-		This puts generating SHA-1 collisions well within the reach of governments,
+      This puts generating SHA-1 collisions well within the reach of
-		malicious organizations, and even well-funded individuals.
+      governments, malicious organizations, and even well-funded individuals.
     </p>
-</section1>
+  </section1>
-<section1 topic='IANA Considerations' anchor='iana'>
+  <section1 topic='IANA Considerations' anchor='iana'>
     <p>
       This document requires no interaction with the Internet Assigned Numbers
       Authority (IANA).
     </p>
-</section1>
+  </section1>
-<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <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>
+  </section1>
 </xep>