juga
/
internet-drafts
forked from pEp.foundation/internet-drafts
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

copy of draft-symeonidis-medup-requirements, prepared for split of documents

master
Bernie Hoeneisen 2019-10-01 11:27:37 +02:00
parent b2607c5d68
commit 6f16a07f1f
2 changed files with 828 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
pearg-analysis/Makefile Normal file
View File

@ -0,0 +1,47 @@
#!/usr/bin/make -f
NAME := draft-symeonidis-pearg-private-messaging-threat-analysis
REV := 00
DRAFT := $(NAME)-$(REV)
OUTPUTS = $(DRAFT).xml $(DRAFT).txt $(DRAFT).html
DATE := $(shell date +%Y%m%d)
all: $(OUTPUTS)
$(DRAFT).xml: $(NAME).mkd \
../shared/author_tags/iraklis_symeonidis.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
../shared/text-blocks/mitm.mkd \
../shared/ascii-arts/basic-msg-flow.mkd \
# ../shared/references/isoc-btn.mkd \
# ../shared/references/implementation-status.mkd \
# ../shared/text-blocks/implementation-status.mkd \
# ../shared/ascii-arts/pep_id_system.mkd \
# to match backslash at the end of the previous line
kramdown-rfc2629 $(NAME).mkd > $(DRAFT).xml
$(DRAFT).txt: $(DRAFT).xml
xml2rfc $(DRAFT).xml
$(DRAFT).html: $(DRAFT).xml
xml2rfc --html $(DRAFT).xml
# copy files to review folder
review: distclean $(DRAFT).txt $(DRAFT).html
mkdir -p review ; \
cp -p $(DRAFT).txt review/$(DRAFT)-pre$(DATE).txt ; \
cp -p $(DRAFT).html review/$(DRAFT)-pre$(DATE).html
clean:
rm -f $(OUTPUTS)
distclean:
rm -f -r $(NAME)-* .refcache
.PHONY: clean all

781
pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd Normal file
View File

@ -0,0 +1,781 @@
---
coding: utf-8
title: "Privacy and Security Threat Analysis for Private Messaging"
abbrev: "Private Messaging: Threat Analysis"
docname: draft-symeonidis-pearg-private-messaging-threat-analysis-00
category: std
stand_alone: yes
pi: [toc, sortrefs, symrefs, comments]
author:
{::include ../shared/author_tags/iraklis_symeonidis.mkd}
#{::include ../shared/author_tags/bernie_hoeneisen.mkd}
normative:
RFC4949:
RFC7435:
informative:
RFC4880:
RFC6973:
# RFC7258:
# RFC7942:
RFC8280:
I-D.birk-pep:
# I-D.marques-pep-email:
I-D.birk-pep-trustwords:
# I-D.marques-pep-rating:
# I-D.marques-pep-handshake:
# I-D.hoeneisen-pep-keysync:
{::include ../shared/references/unger-sok.mkd}
{::include ../shared/references/pfitzmann-terminology-privacy.mkd}
{::include ../shared/references/tor-timing-attacks.mkd}
{::include ../shared/references/diaz-measuring-anonymity.mkd}
{::include ../shared/references/ermoshina-end2end-enc.mkd}
{::include ../shared/references/clark-seuring-email.mkd}
# {::include ../shared/references/isoc-btn.mkd}
# {::include ../shared/references/implementation-status.mkd}
--- abstract
{{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.
--- middle
# Introduction
{{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.
In MEDUP these issues are addressed based on Opportunistic Security
{{RFC7435}} principles.
This documents covers analysis of threats to privacy and
security and derives requirements from this threat analysis.
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
{::include ../shared/text-blocks/terms-intro.mkd}
<!-- {::include ../shared/text-blocks/handshake.mkd} -->
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
{::include ../shared/text-blocks/mitm.mkd}
<!--
**[Iraklis]: I copied [nk] feedback here below. It is a very valid
comment; thinking were that text can have a better fit in the RFC.
**[nk] I would encourage to add one para saying that the threat model
also depends on the background of the user (in specific if lives are
at stake), e.g., investigative journalists, whistle-blowers or
dissidents from repressive countries do have much more severe
requirements than organisaions than "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).
-->
# Motivation and Background
## Objectives
* An open standard for secure messaging requirements
* Unified evaluation framework: unified goals and threat models
* Common pitfalls
* Future directions on requirements and technologies
* Misleading products on the wild (EFF secure messaging scorecard)
## Known Implementations
### Pretty Easy Privacy (pEp) {#pEp}
To achieve privacy of exchanged messages in an opportunistic way
{{RFC7435}}, the following model (simplified) is proposed by pEp
(pretty Easy Privacy) {{I-D.birk-pep}}:
{::include ../shared/ascii-arts/basic-msg-flow.mkd}
<vspace blankLines="10" />
<!-- pEp is using the paradigm to have online and offline transports.
On offline transport is transporting messages by store and
forward. The connection status of the receiver is not important while
sending, and it may be not available at all. Examples are Internet
Mail and SMS.
An online transport is transporting messages synchronously to
receivers if those are online. If receivers are offline, no message
can be transported. The connection status of an receiver is available
to the sender. Examples are Jabber and IRC. -->
pEp is intended to solve three problems <!-- for both types of
transports -->:
* Key management
* Trust management
* Identity management
pEp is intended to be used in pre-existing messaging solutions and
provide Privacy by Default, at a minimum, for message content. In
addition, pEp provides technical data protection including metadata
protection.
An additional set of use cases applies to enterprise environments
only. In some instances, the enterprise may require access to message
content. Reasons for this may include the need to conform to
compliance requirements or virus/malware defense.
### Autocrypt
Another known approach in this area is Autocrypt. Compared to pEp
(cf. {{pEp}}) - there are certain differences, for example, regarding
the prioritization of support for legacy PGP {{RFC4880}}
implementations.
More information on Autocrypt can be found on:
https://autocrypt.org/background.html
\[\[ TODO: Input from autocrypt group \]\]
## Focus Areas (Design Challenges):
* Trust establishment: some human interaction
* Conversation security: no human interaction
* Transport privacy: no human interaction
# System Model
## Entities
* Users, sender and receiver(s): The communicating parties who
exchange messages, typically referred to as senders and receivers.
* Messaging operators and network nodes: The communicating service
providers and network nodes that are responsible for message
delivery and synchronization.
* Third parties: Any other entity who interacts with the messaging
system.
## Basic Functional Requirements
This section outlines the functional requirements. We follow the
requirements extracted from the literature on private emails and
instant messaging {{Unger}} {{Ermoshina}} {{Clark}}.
* Message: send and receive message(s)
* Multi-device support: synchronization across multiple devices
* Group messaging: communication of more than 2 users
\[\[ TODO: Add more text on Group Messaging requirements. \]\]
# Threat Analyses
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
communication system, whose goal is to gain improper access to the
message content and users' information. They can be anyone who is
involved in communication, such as users of the system, message
operators, network nodes, or even third parties.
* Internal - external: An adversary can seize control of entities
within the system, such as extracting information from a specific
entity or preventing a message from being sent. An external
adversary can only compromise the communication channels themselves,
eavesdropping and tampering with messaging such as performing
Man-in-the-Middle (MitM) attacks.
* Local - global: A local adversary can control one entity that is
part of a system, while a global adversary can seize control of
several entities in a system. A global adversary can also monitor
and control several parts of the network, granting them the ability
to correlate network traffic, which is crucial in performing timing
attacks.
* Passive - active: A passive attacker can only eavesdrop and extract
information, while an active attacker can tamper with the messages
themselves, such as adding, removing, or even modifying them.
Attackers can combine these adversarial properties in a number of
ways, increasing the effectiveness - and probable success - of their
attacks. For instance, an external global passive attacker can
monitor multiple channels of a system, while an internal local active
adversary can tamper with the messages of a targeted messaging
provider {{Diaz}}.
## Security Threats and Requirements
### Spoofing and Entity Authentication
Spoofing occurs when an adversary gains improper access to the system
upon successfully impersonating the profile of a valid user. The
adversary may also attempt to send or receive messages on behalf of
that user. The threat posed by an adversary's spoofing capabilities is
typically based on the local control of one entity or a set of
entities, with each compromised account typically is used to
communicate with different end-users. In order to mitigate spoofing
threats, it is essential to have entity authentication mechanisms in
place that will verify that a user is the legitimate owner of a
messaging service account. The entity authentication mechanisms
typically rely on the information or physical traits that only the
valid user should know/possess, such as passwords, valid public keys,
or biometric data like fingerprints.
### Information Disclosure and Confidentiality
An adversary aims to eavesdrop and disclose information about the
content of a message. They can attempt to perform a man-in-the-middle
attack (MitM). For example, an adversary can attempt to position
themselves between two communicating parties, such as gaining access
to the messaging server and remain undetectable while collecting
information transmitted between the intended users. The threat posed
by an adversary can be from local gaining control of one point of a
communication channel such as an entity or a communication link within
the network. The adversarial threat can also be broader in scope, such
as seizing global control of several entities and communication links
within the channel. That grants the adversary the ability to correlate
and control traffic in order to execute timing attacks, even in the
end-to-end communication systems {{Tor}}. Therefore, confidentiality
of messages exchanged within a system should be guaranteed with the
use of encryption schemes
### Tampering With Data and Data Authentication
An adversary can also modify the information stored and exchanged
between the communication entities in the system. For instance, an
adversary may attempt to alter an email or an instant message by
changing the content of them. As a result, it can be anyone but the
users who are communicating, such as the message operators, the
network node, or third parties. The threat posed by an adversary can
be in gaining local control of an entity which can alter messages,
usually resulting in a MitM attack on an encrypted channel. Therefore,
no honest party should accept a message that was modified in
transit. Data authentication of messages exchanged needs to be
guaranteed, such as with the use of Message Authentication Code (MAC)
and digital signatures.
### Repudiation and Accountability (Non-Repudiation)
Adversaries can repudiate, or deny, the status of the message to users
of the system. For instance, an adversary may attempt to provide
inaccurate information about an action performed, such as about
sending or receiving an email. An adversary can be anyone who is
involved in communicating, such as the users of the system, the
message operators, and the network nodes. To mitigate repudiation
threats, accountability, and non-repudiation of actions performed must
be guaranteed. Non-repudiation of action can include proof of origin,
submission, delivery, and receipt between the intended
users. Non-repudiation can be achieved with the use of cryptographic
schemes such as digital signatures and audit trails such as
timestamps.
## Privacy Threats and Requirements
### Identifiability -- Anonymity
Identifiability is defined as the extent to which a specific user can
be identified from a set of users, which is the identifiability
set. Identification is the process of linking information to allow the
inference of a particular user's identity {{RFC6973}}. An adversary
can identify a specific user associated with Items of Interest (IOI),
which include items such as the ID of a subject, a sent message, or an
action performed. For instance, an adversary may identify the sender
of a message by examining the headers of a message exchanged within a
system. To mitigate identifiability threats, the anonymity of users
must be guaranteed. Anonymity is defined from the attackers
perspective as the "the attacker cannot sufficiently identify the
subject within a set of subjects, the anonymity set"
{{Pfitzmann}}. Essentially, in order to make anonymity possible, there
always needs to be a set of possible users such that for an adversary
the communicating user is equally likely to be of any other user in
the set {{Diaz}}. Thus, an adversary cannot identify who is the sender
of a message. Anonymity can be achieved with the use of pseudonyms and
cryptographic schemes such as anonymous remailers (i.e., mixnets),
anonymous communications channels (e.g., Tor), and secret sharing.
### Linkability -- Unlinkability
Linkability occurs when an adversary can sufficiently distinguish
within a given system that two or more IOIs such as subjects (i.e.,
users), objects (i.e., messages), or actions are related to each other
{{Pfitzmann}}. For instance, an adversary may be able to relate
pseudonyms by analyzing exchanged messages and deduce that the
pseudonyms belong to one user (though the user may not necessarily be
identified in this process). Therefore, unlinkability of IOIs should
be guaranteed through the use of pseudonyms as well as cryptographic
schemes such as anonymous credentials.
### Detectability and Observability -- Undetectability
Detectability occurs when an adversary is able to sufficiently
distinguish an IOI, such as messages exchanged within the system, from
random noise {{Pfitzmann}}. Observability occurs when that
detectability occurs along with a loss of anonymity for the entities
within that same system. An adversary can exploit these states in
order to infer linkability and possibly identification of users within
a system. Therefore, undetectability of IOIs should be guaranteed,
which also ensures unobservability. Undetectability for an IOI is
defined as that "the attacker cannot sufficiently distinguish whether
it exists or not." {{Pfitzmann}}. Undetectability can be achieved
through the use of cryptographic schemes such as mix-nets and
obfuscation mechanisms such as the insertion of dummy traffic within a
system.
## Information Disclosure -- Confidentiality
Information disclosure -- or loss of confidentiality -- about users,
message content, metadata or other information is not only a security
but also a privacy threat that a communicating system can face. For
example, a successful MitM attack can yield metadata that can be used
to determine with whom a specific user communicates with, and how
frequently. To guarantee the confidentiality of messages and prevent
information disclosure, security measures need to be guaranteed with
the use of cryptographic schemes such as symmetric, asymmetric or
homomorphic encryption and secret sharing.
## Non-repudiation and Deniability
Non-repudiation can be a threat to a user's privacy for private
messaging systems, in contrast to security. As discussed in section
6.1.4, non-repudiation should be guaranteed for users. However,
non-repudiation carries a potential threat vector in itself when it is
used against a user in certain instances. For example, whistle-blowers
may find non-repudiation used against them by adversaries,
particularly in countries with strict censorship policies and in cases
where human lives are at stake. Adversaries in these situations may
seek to use shreds of evidence collected within a communication system
to prove to others that a whistle-blowing user was the originator of a
specific message. Therefore, plausible deniability is essential for
these users, to ensure that an adversary can neither confirm nor
contradict that a specific user sent a particular message. Deniability
can be guaranteed through the use of cryptographic protocols such as
off-the-record messaging.
<!-- =================================================================== -->
<vspace blankLines="4" />
\[\[ TODO: Describe relation of the above introduced Problem Areas to
scope of MEDUP \]\]
<!--
# Scope of MEDUP
As some of the above introduced Problem Areas {{problem-areas}}
conflict with each other or other ares of MEDUP, those need to
prioritized.
## Problem Areas addressed by MEDUP
In MEDUP the following of the above introduced Problem Areas
{{problem-areas}} will be addressed primarily:
\[\[TODO: Move some of this this to next subsection \]\]
* Spoofing and Entity Authentication
(cf. {{spoofing-and-entity-authentication}})
* Information Disclosure and Confidentiality
(cf. {{information-disclosure-and-confidentiality}})
* Tampering With Data and Data Authentication
(cf. {{tampering-with-data-and-data-authentication}})
* Repudiation and Accountability (Non-Repudiation)
(cf. {{repudiation-and-accountability-non-repudiation}})
* Identifiability -\- Anonymity (cf. {{identifiability-anonymity}})
* Linkability -\- Unlinkability (cf. {{linkability-unlinkability}})
* Detectability and Observatility -\- Unditectability
(cf. {{detectability-and-observatility-unditectability}})
* Information Disclosure -\- Confidentiality
(cf. {{information-disclosure-confidentiality}})
* Non-Repudiation and Deniability
(cf. {{non-repudiation-and-deniability}})
## Problem Areas addressed by MEDUP
The following of the above introduced Problem Areas {{problem-areas}}
MAY be addressed in MEDUP only to the extent as they are not in
conflict with the Problem Areas addressed by MEDUP.
* ...
\[\[TODO: Move some of this this from previous subsection \]\]
-->
<!-- =================================================================== -->
# Specific Security and Privacy Requirements
\[\[ This section is still in early draft state, to be substantially
improved in future revisions. Among other things, there needs to be
clearer distinction between MEDUP requirements, and those of a
specific implementation.
\]\]
## Messages Exchange
### Send Message
* Send encrypted and signed message to another peer
* Send unencrypted and unsigned message to another peer
Note: Subcases of sending messages are outlined in
{{subcases-for-sending-messages}}.
### Receive Message
* Receive encrypted and signed message from another peer
* Receive encrypted, but unsigned message from another peer
* Receive signed, but unencrypted message from another peer
* Receive unencrypted and unsigned message from another peer
Note: Subcases of receiving messages are outlined in
{{subcases-for-receiving-messages}}.
## Trust Management
* Trust rating of a peer is updated (locally) when:
* Public Key is received the first time
* Trustwords have been compared successfully and confirmed by user
(see above)
* Trust of a peer is revoked (cf. {{key-management}}, Key Reset)
* Trust of a public key is synchronized among different devices of the
same user
Note: Synchronization management (such as the establishment or
revocation of trust) among a user's own devices is described in
{{synchronization-management}}
## Key Management
* New Key pair is automatically generated at startup if none are found.
* Public Key is sent to peer via message attachment
* Once received, Public Key is stored locally
* Key pair is declared invalid and other peers are informed (Key Reset)
* Public Key is marked invalid after receiving a key reset message
* Public Keys of peers are synchronized among a user's devices
* Private Keys are synchronized among a user's devices
Note: Synchronization management (such as establish or revoke trust)
among a user's own devices is described in
{{synchronization-management}}
## Synchronization Management
A device group is comprised of devices belonging to one user, which
share the same key pairs in order to synchronize data among them. In
a device group, devices of the same user mutually grant
authentication.
* Form a device group of two (yet ungrouped) devices of the same user
<!--
Note: Preconditions for forming a device group are outlined in
{{preconditions-for-forming-a-device-group}}.
-->
* Add another device of the same user to existing device group
* Leave device group
* Remove other device from device group
## Identity Management
* All involved parties share the same identity system
## User Interface
\[\[ TODO \]\]
<!--
* Need for user interaction is kept to the minimum necessary
* The privacy status of a peer is presented to the user in a easily
understandable way, e.g. by a color rating
* The privacy status of a message is presented to the user in a easily
understandable way, e.g. by a color rating
* The color rating is defined by a traffic-light semantics
\[\[ TODO: rewrite "in a easily understandable way} \]\]
-->
# Subcases
<!-- Do we need this section at all? -->
## Interaction States
The basic model consists of different interaction states:
<!-- nk] you might consider changing the numbers, to a three-fold
system (for 3 different cases). And repeat the same numbering with
differentiating them in the subcases in the table below. Also it would
be good to have some explanation when or why these cases occur, maybe
link them with a timeline of starting and establishing a conversation
as well as an explicit reference to the TOFU concept. -->
1. Both peers have no public key of each other, no trust possible
2. Only one peer has the public key of the other peer, but no trust
3. Only one peer has the public key of the other peer and trusts
that public key
4. Both peers have the public key of each other, but no trust
5. Both peers have exchanged public keys, but only one peer trusts the
other peer's public key
6. Both peers have exchanged public keys, and both peers trust the
other's public key
The following table shows the different interaction states possible:
| state | Peer's Public Key available | My Public Key available to Peer | Peer Trusted | Peer trusts me |
| ------|:---------------------------:|:-------------------------------:|:------------:|:--------------:|
| 1. | no | no | N/A | N/A |
| 2a. | no | yes | N/A | no |
| 2b. | yes | no | no | N/A |
| 3a. | no | yes | N/A | yes |
| 3b. | yes | no | yes | N/A |
| 4. | yes | yes | no | no |
| 5a. | yes | yes | no | yes |
| 5b. | yes | yes | yes | no |
| 6. | yes | yes | yes | yes |
In the simplified model, only interaction states 1, 2, 4 and 6 are
depicted. States 3 and 5 may result from e.g. key mistrust or abnormal
user behavior. Interaction states 1, 2 and 4 are part of
TOFU. For a better understanding, you may consult the figure in
{{pEp}} above.
Note: In situations where one peer has multiple key pairs, or group
conversations are occurring, interaction states become increasingly
complex. For now, we will focus on a single bilateral interaction
between two peers, each possessing a single key pair.
\[\[ Note: Future versions of this document will address more complex
cases \]\]
## Subcases for Sending Messages
* If peer's Public Key not available (Interaction States 1, 2a, and
3a)
* Send message Unencrypted (and unsigned)
* If peer's Public Key available (Interaction States 2b, 3b, 4, 5a,
5b, 6)
* Send message Encrypted and Signed
## Subcases for Receiving Messages
* If peer's Public Key not available (Interaction States 1, 2a, and
3a)
* If message is signed
* ignore signature
* If message is encrypted
* decrypt with caution
* If message unencrypted
* No further processing regarding encryption
* If peer's Public Key available or can be retrieved from received
message (Interaction States 2b, 3b, 4, 5a, 5b, 6)
* If message is signed
* verify signature
* If message is encrypted
* Decrypt
* If message unencrypted
* No further processing regarding encryption
* If message unsigned
* If message is encrypted
* exception
* If message unencrypted
* No further processing regarding encryption
<!-- =================================================================== -->
# Security Considerations
Relevant security considerations are outlined in
{{security-threats-and-requirements}}.
# Privacy Considerations
Relevant privacy considerations are outlined in
{{privacy-threats-and-requirements}}.
# IANA Considerations
This document requests no action from IANA.
\[\[ RFC Editor: This section may be removed before publication. \]\]
# Acknowledgments
The authors would like to thank the following people who have provided
feedback or significant contributions to the development of this
document: Athena Schumacher, Claudio Luck, Hernani Marques, Kelly
Bristol, Krista Bennett, and Nana Karlstetter.
--- back
# Document Changelog
\[\[ RFC Editor: This section is to be removed before publication \]\]
* draft-symeonidis-pearg-private-messaging-threat-analysis-00:
* Initial version
# Open Issues
\[\[ RFC Editor: This section should be empty and is to be removed
before publication \]\]
* Add references to used materials (in particular threat analyses part)
* Get content from Autocrypt ({{autocrypt}})
* Add more text on Group Messaging requirements
* Decide on whether or not "enterprise requirement" will go to this
document
<!-- LocalWords: utf docname symeonidis medup toc sortrefs symrefs
-->
<!-- LocalWords: vspace blankLines pre Autocrypt autocrypt Unger
-->
<!-- LocalWords: Ermoshina MitM homomorphic IOI Diaz remailers IOIs
-->
<!-- LocalWords: mixnets Linkability Unlinkability unlinkability
-->
<!-- LocalWords: Detectability observatility Unditectability Nana
-->
<!-- LocalWords: undetectability Pfitzmann Subcases subcases
-->
<!-- LocalWords: ungrouped Identifiability Changelog Schumacher
-->
<!-- LocalWords: Karlstetter
-->