diff --git a/misc/kramdown/.slides-92-edu-kramdown.pdf.icloud b/misc/kramdown/.slides-92-edu-kramdown.pdf.icloud new file mode 100644 index 00000000..c9a63bf6 Binary files /dev/null and b/misc/kramdown/.slides-92-edu-kramdown.pdf.icloud differ diff --git a/misc/kramdown/slides-92-edu-kramdown.pdf b/misc/kramdown/slides-92-edu-kramdown.pdf deleted file mode 100644 index b99c0e0c..00000000 Binary files a/misc/kramdown/slides-92-edu-kramdown.pdf and /dev/null differ diff --git a/pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd b/pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd index 847cc9a2..d7cd68d5 100644 --- a/pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd +++ b/pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd @@ -50,24 +50,23 @@ Modern email and instant messaging applications offer private communications, sh # Introduction -Private messaging should ensure that, in an exchange of messages between (two) peers, no one but the sender and the receiver of the communication will be capable of reading the messages exchanged at any (current, future or past) time. That means, no one but the communicating peers should ever have access to the messages during transit and storage such as, telecom, internet providers, messaging servers or intermediary parties. As private messaging we are referring to instant messaging (IM) {{RFC 2779 Instant Messaging}}, such as WhatsApp and Signal, and to email applications (E), such as the centralized Protonmail and the fully decentralized pep {{birk-pep-04}}. +Private messaging should ensure that, in an exchange of messages between (two) peers, no one but the sender and the receiver of the communication will be capable of reading the messages exchanged at any (current, future or past) time. That means, no one but the communicating peers should ever have access to the messages during transit and storage such as telecom, internet providers, messaging servers or intermediary parties. As private messaging, we are referring to instant messaging (IM) {{RFC 2779 Instant Messaging}}, such as WhatsApp and Signal, and email applications (E), such as the centralized Protonmail and the fully decentralized pep {{birk-pep-04}}. -The aim of this current document (RFC draft) is to provide an open standard for private messaging requirements. It focuses on a unified evaluation framework. The framework catalogs the security and privacy threats and as well as the corresponding, to threats, requirements for private messaging. IM and E applications have common feature design characteristics and support a common set of information assets for transmission during communication between peers. For example, applications for both systems should support message exchange of text and files (e.g., attachments) in a private messaging manner. +The aim of this current document (RFC draft) is to provide an open standard for private messaging requirements. It aims to provide a unified evaluation framework. The framework catalogues security and privacy threats and the corresponding requirements. IM and E applications have common feature design characteristics and support a common set of information assets for transmission during communication between peers. For example, applications for both systems should support message exchange of text and files (e.g., attachments) in a private messaging manner. -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). +It is necessary 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. -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). +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 in multiple wasy and 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 than organizations 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 the second priority in favour of solutions offering more profound protection. -The objectives of this document is to: +The objectives of this document are to 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. -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 +# Of course, IM additionally can support voice/video calls, which is an additional feature/asset under which a treat assessment and requirements can be evaluated. +