From 4a6916732e376af1ab13efbb676f283ffe173288 Mon Sep 17 00:00:00 2001
From: Sarah Jamie Lewis <sarah@openprivacy.ca>
Date: Thu, 25 Jun 2020 11:20:56 -0700
Subject: [PATCH] groups, deployment and servers

---
 src/SUMMARY.md    |  1 +
 src/deployment.md | 20 ++++++++++++++++
 src/groups.md     | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 src/references.md |  6 +++++
 src/server.md     |  4 ++--
 5 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 src/references.md

diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 32df8ae..2834016 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -10,4 +10,5 @@
 - [Cwtch Server](./server.md)
 - [Development](./development.md)
 - [Deployment](./deployment.md)
+- [References](./references.md)
 
diff --git a/src/deployment.md b/src/deployment.md
index d36c65e..8a6c9e8 100644
--- a/src/deployment.md
+++ b/src/deployment.md
@@ -1 +1,21 @@
 # Deployment
+
+
+##  Risk: Binaries are replaced on the website with malicious ones
+
+**Status: Unmitigated**
+
+While this process is now mostly automated, should this automation ever be
+compromised then there is nothing in our current process that would detect this.
+
+We need:
+
+* Reproducible Builds - it is unlikely that we will be able to do this
+ overnight, several parts of our build process (Qt builds, the recipe etc.)
+ may introduce non-determinism. Nevertheless, we should seek to identify where
+ this non-determinism is.
+ * Signed Releases - Open Privacy does not yet maintain a public record of staff
+ public keys. This is likely a necessity for signing released builds and
+  creating an audit chain backed by the organization. This process must be
+  manual by definition.
+  
diff --git a/src/groups.md b/src/groups.md
index e97b3e9..9900fb9 100644
--- a/src/groups.md
+++ b/src/groups.md
@@ -1 +1,60 @@
 # Groups
+
+For the most part the Cwtch risk model for groups is split into two distinct
+profiles:
+
+* Groups made up of mutually trusted participants where peers are assumed
+ honest.
+* Groups consisting of strangers where peers are assumed to be potentially
+ malicious.
+ 
+Most of the mitigations described in this section relate to the latter case, but
+naturally also impact the former. Even if assumed honest peers later turn
+ malicious there are mechanisms that can detect such malice and prevent it from
+ happening in the future.
+ 
+## Risk Overview: Key Derivation
+
+In the ideal case we would use a protocol like OTR, the limitations preventing
+us from doing so right now are:
+
+* Offline messages are not guaranteed to reach all peers, and as such any
+metadata relating to key material might get lost. We need a key derivation
+ process which is robust to missing messages or incomplete broadcast. 
+ 
+## Risk: Malicious Peer Leaks Group Key and/or Conversation
+
+**Status: Partially Mitigated (but impossible to mitigate fully)**
+
+Whether dealing with trusted smaller groups or partially-public larger groups
+there is *always* the possibility that a malicious actor will leak group
+messages.
+  
+We plan to make it easy for peers to [fork](#fork) groups to mitigate the
+ same key being used to encrypt lots of sensitive information and provide
+  some level of forward secrecy for past group conversations.
+
+## Risk: Active Attacks by Group Members
+
+**Status: Partially Mitigated**
+
+Group members, who have access to the key material of the group, can conspire
+ with a server or other group members to break transcript consistency.
+
+While we cannot directly prevent censorship given this kind of active
+ collusion, we have a number of mechanisms in place that should reveal the
+ presence of censorship to honest members of the group. 
+ 
+### Mitigations:
+ 
+* Because each message is signed by the peers public key, it should not be
+possible (within the cryptographic assumptions of the underlying cryptography)
+for one group member to imitate another.
+* Each message contains a unique identifier derived from the contents and the
+previous message hash - making it impossible for collaborators to include
+messages from non-colluding members without revealing an implicit message
+chain (which if they were attempting to censor other messages would
+ reveal such censorship)
+ 
+Finally: We are actively working on adding non-repudiation to Cwtch servers such
+that they themselves are restricted in what they can censor efficiently.
\ No newline at end of file
diff --git a/src/references.md b/src/references.md
new file mode 100644
index 0000000..778f265
--- /dev/null
+++ b/src/references.md
@@ -0,0 +1,6 @@
+# References
+
+* Nik Unger et al. “SoK: secure messaging”. In:Security and Privacy (SP
+ ), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)
+ 
+ 
diff --git a/src/server.md b/src/server.md
index af4d4b7..05575a0 100644
--- a/src/server.md
+++ b/src/server.md
@@ -60,8 +60,8 @@ privacy and efficiency guarantees can be traded-off in different ways.
 
 The most developed idea is to bucket the messages on the server into discrete
 time windows and allow peers to fetch smaller batches, coupled with the
- underlying tor connection this technique should provide sufficient privacy
-  - although the technique still needs formal verification.
+ underlying tor connection this technique should provide sufficient privacy - 
+ although the technique still needs formal verification.
   
 # Protecting the Server from Malicious Peers