From c650d1881fc81df6db75e11d8a6d29eeb956a871 Mon Sep 17 00:00:00 2001
From: Steve Kille <steve.kille@isode.com>
Date: Tue, 2 Jan 2018 10:34:45 +0000
Subject: [PATCH] Address security concersn in Converting a 1:1 Conversation to
 a Channel

---
 xep-0369.xml | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xep-0369.xml b/xep-0369.xml
index 97e0a7aa..0a32f70e 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -50,6 +50,7 @@
       Allow servers to limit retract time frame,
       Clarify that private messages must not be groupchat,
       Creating Channel Clarification,
+      Address security concerns on Converting a 1:1 Conversation to a Channel, 
       
     </p></remark>
   </revision>  <revision>
@@ -2154,7 +2155,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
      </p>
      <p>
        It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel.  The mechanism to do this is to forward messages to be shared in the MUC using &xep0297;.  A body SHOULD NOT be used in the outer message.
-       This will generally be done by the user creating the channel before the other user is invited, but MAY be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.
+       Sharing history is optional.   If history is shared, it MUST be done by the user creating the channel before the other user is invited.   Any other use of forwarded messages MUST be treated as a member of the MUC forwarding a message to the channel and MUST NOT be treated as history sharing.
      </p>
      <example caption="Forwarding a message to create History" ><![CDATA[
 <message from='hag66@shakespeare.example/UUID-a1j/7533'
@@ -2173,6 +2174,9 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         </forwarded>
 </message>
 ]]></example>
+     <p>
+       There are a number of security considerations with use of MUC history.   There may be sensitive information in the 1:1 MUC history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way.   The user creating the MUC has potential to inject history messages which were not part of the history.   It is recommended that the second user joining the MUC to validate that the messages match the history and to take appropriate action if they do not.   
+     </p>
    </section3>
 
     <section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
@@ -2759,6 +2763,9 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   <p>
     MIX provides flexible access control options, which MUST be used in a manner appropriate to the security requirements of MIX users and services.
   </p>
+  <p>
+    When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
+  </p>
 
 </section1>