0.2 RC1 Clarified introduction

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@873 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0210.xml

@@ -66,6 +66,12 @@
   <supersededby>None</supersededby>
   <shortname>NOT YET ASSIGNED</shortname>
   &ianpaterson;
+  <revision>
+    <version>0.2</version>
+    <date>2007-05-30</date>
+    <initials>ip</initials>
+    <remark><p>Clarified introduction.</p></remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2007-04-20</date>
@@ -75,9 +81,11 @@
 </header>
 
 <section1 topic='Introduction' anchor='intro'>
-  <p>Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone storeable object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.</p>
-  <p>However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of much more secure approaches to encryption (including Perfect Forward Secrecy) that are not feasible for less dynamic technologies (like email). The focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &zrtp; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc4346;) or IPsec (see &rfc4301;) than to traditional encryption of files and standalone email messages.</p>
+  <p>Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.</p>
+  <p>However, encryption schemes that are appropriate for less dynamic Internet technologies are not appropriate for session-oriented communication technologies like XMPP. With XMPP the receiver is typically connected to its server at the time the message is sent, so XMPP can take advantage of much more secure session-oriented approaches to encryption - approaches that are not feasible for less dynamic technologies like email. Most importantly, XMPP can benefit from <link url='#reqs-forward'>Perfect Forward Secrecy</link> and <link url='#reqs-id-protect'>Identity Protection</link>.</p>
+  <p>Therefore, for XMPP, the focus should be on "session encryption" rather than "object encryption". The paradigm should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &zrtp; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc4346;) or IPsec (see &rfc4301;) than to the traditional encryption of files and email messages.</p>
   <p>The session metaphor applies to communication between any two XMPP endpoints. For instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).</p>
+  <p>Note: The encryption of archived messages is necessarily less secure than session encryption. The encryption of such stored messages is described in &xep0136; and is therefore out-of-scope for this document.</p>
 </section1>
 
 <section1 topic='Scope' anchor='scope'>
@@ -87,7 +95,7 @@
     <li>One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see &rfc3921;) and data syndication implemented using &xep0060;.</li>
     <li>One-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".</li>
   </ul>
-  <p>Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this document.</p>
+  <p>Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out-of-scope for this document.</p>
   <p>Communications where the receiving entity is offline should ideally be handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously. This approach enables code reuse, minimises the points of failure and significantly increases the security (for example, by providing Perfect Forward Secrecy).</p>
 </section1>
 
@@ -128,7 +136,7 @@
     <p>No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. So, even if Alice and Bob protect their identities by using different JIDs for each session, it MUST be possible for their clients to authenticate them transparently, without any other entity identifying them via an active ("man-in-the-middle") attack, or even linking them to their previous sessions. If that is not possible because Alice and Bob choose to authenticate using public keys instead of retained shared secrets, then the public keys MUST NOT be revealed to other entities using a passive attack. Bob MUST also be able to choose between protecting either his public key or Alice's public key from disclosure through an active attack.</p>
   </section2>
   <section2 topic='Repudiability' anchor='reqs-repudiate'>
-    <p>Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it MUST NOT be possible to <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this document.</note></p>
+    <p>Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it MUST NOT be possible to <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out-of-scope for this document.</note></p>
   </section2>
   <section2 topic='Robustness' anchor='reqs-robust'>
     <p>The protocol SHOULD provide more than one difficult challenge that has to be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible - like retained secrets or optional passwords).</p>