{{RFC8280}} has identified and documented important principles, such
as Data Minimization, End-to-End, and Interoperability in order to
enable access to fundamental Human Rights. While (partial)
implementations of these concepts are already available, many current
applications lack Privacy support that the average user can easily
navigate. This document covers analysis of threats to privacy and
security and derives requirements from this threat analysis.
Modern email and instant messaging applications offer private communications, sharing common concerns about how security and privacy can be compromised. The solutions available to mitigate the threats and to comply with the requirements may differ though. The two applications are in fact built on different assumptions and technologies. Assuming a scenario of untrusted servers, we discuss those threats against message delivering and archiving, the requirements that come with them, and the solutions that exist to help implement a secure and private messaging.
--- middle
@ -62,32 +56,24 @@ The aim of this current document (RFC draft) is to provide an open standard for
It is essential to highlight that IM and EM have network design divergences such as responsiveness and synchronicity. For example, low-latency and synchronous were the common features for instant messaging and high-latency and asynchronous for emailing. However, nowadays IM applications tend to be asynchronous allowing delivery of messages when the communicating parties are not at the same time online. Of course, IM additionally can support voice/video calls, which is an additional feature/asset under which a treat assessemment and requirements can be evaluated (non english).
Solutions available to implement private messaging in the two types of applications may call for different mitigation mechanisms and design choices. For instance, confidentiality can be preserved with various cryptographic primitives. As design choices it depends on the expected level of protection and the background of the user. For example, in specific where lives are at stake such as investigative journalists, whistle-blowers or dissidents from repressive countries the design choice for requirements and mitigation mechanism can be much more advanced (check) than organisations and "normal" people from the broad public. Yet, Privacy and Security on the Internet always are Human Rights and technological solutions should enable easily usable means to protect. But if somebody requires stronger protection, usability may be a second priority in favour of solutions offering a more profound protection (also hardware questions factor in more in these latter cases).
Solutions available to implement private messaging in the two types of applications may call for different mitigation mechanisms and design choices. For instance, confidentiality can be preserved with various cryptographic primitives. As design choices it depends on the expected level of protection and the background of the user. For example, in specific where lives are at stake such as investigative journalists, whistle-blowers or dissidents from repressive countries the design choice for requirements and mitigation mechanism can be much more advanced (check) than organisations and "normal" users from the broad public. Yet, privacy and security on the Internet always are Human Rights and technological solutions should enable easily usable means to protect. But if somebody requires stronger protection, usability may be a second priority in favour of solutions offering a more profound protection (also hardware questions factor in more in these latter cases).
The objectives of this document is to:
* Create an open standard for secure messaging requirements. The open standard for private messaging aims to serve as unified evaluation framework (adversarial model, threats and requirements). With this document we catalogue the threats and requirements for implementing secure and private messaging systems. We focus on assets, threats/requirements and type of users utilizing private messaging systems. In this current version, we focus on two key design features of IM and EM, namely message delivering and message archiving, and so the work is on-going and the list of requirements we discuss here is not exhaustive. However, our work already shows an emerging and rich set of security and privacy challenges. Besides, several security and privacy mechanisms are available to address those challenges and herein we discuss them too (check again).
Create an open standard for secure messaging requirements. The open standard for private messaging aims to serve as unified evaluation framework (i.e., adversarial model, threats and requirements). With this document we catalogue the threats and requirements for implementing secure and private messaging systems. We focus on assets, threats/requirements and type of users utilizing private messaging systems. In this current version, we focus on two key design features of IM and EM, namely message delivering and message archiving, and so the work is on-going and the list of requirements we discuss here is not exhaustive. However, our work already shows an emerging and rich set of security and privacy challenges. Besides, several security and privacy mechanisms are available to address those challenges and herein we discuss them too (check again).
* Common pitfalls
* Future directions on requirements and technologies
# Background
<!-
ß# Background
dev a system considering as a basis
selection of Threats
anyboby who is building a system could refer to That
## Focus Areas (Design Challenges):
* Trust establishment: some human interaction
* Conversation security: no human interaction
* Transport privacy: no human interaction
-->
# System Model
@ -103,22 +89,28 @@ anyboby who is building a system could refer to That
* Third parties: Any other entity who interacts with the messaging
system.
## Basic Functional Requirements
## Assets and functional Requirements
This section outlines a private messaging system. It describes the functionalities that needs to support and the information, as users' assets, that can be collected by the system. We follow the requirements extracted from real world systems and applications as well as from the academic literature for private emails and instant messaging {{Unger}} {{Ermoshina}} {{Clark}}.
This section outlines the functional requirements. We follow the
requirements extracted from the literature on private emails and
* Multi-device support: synchronization across multiple devices
* Group messaging: communication of more than 2 users
Functionalities:
* [E/IM] Messages: send and receive text + attachments
* * Peer or group: more than 2 participants communicating
* [IM] Voice / video call
* [E/IM] Archive and search: of messages and attachments
* [E/IM] Contacts: synchronisation and matching
* [E/IM] Multi-device support: synchronisation across multiple devices
# Threat Analyses and requirements
This section describes a set of possible threats. Note that not all
threats can be addressed, due to conflicting requirements.
## Adversarial model
An adversary is any entity who leverages threats against the
@ -219,6 +211,10 @@ users. Non-repudiation can be achieved with the use of cryptographic
schemes such as digital signatures and audit trails such as
timestamps.
### Elevation of privilege and authorisation
An adversary may attempt to elevate the privileges that has aiming to gain access to the assets of other users and the resources of the system. For instance, an adversary may attempt to become an administrator of a message group or a superuser of the system aiming at retrieving users' messages or executing operations as a super user. Therefore, authorisation mechanisms such as access control lists that comply with the principle of least privilege for user accounts and processes should be applied.
## Privacy Threats and Requirements
### Identifiability -- Anonymity
@ -303,8 +299,10 @@ contradict that a specific user sent a particular message. Deniability
can be guaranteed through the use of cryptographic protocols such as
Policy non-compliance can be a threat to the privacy of users in a private messaging system. An adversary, can attempt to process information about users unlawfully and not-compliant to regulations. It may attempt to collect and process information of users exchanged in emails without the users' notification and explicit consent. That can result in unauthorised prosessing of users information under the General Data Protection Regulation resulting in of such as profiling, advertisement and censorship. Therefore, data protection policy compliance must be guaranteed. It can be achieved with auditing such as with Data Protection Impact Assessment considering GDPR {{gdpr}}.
