forked from pEp.foundation/internet-drafts
copy of draft-symeonidis-medup-requirements, prepared for split of documents
parent
b2607c5d68
commit
6f16a07f1f
|
@ -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
|
|
@ -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
|
||||
-->
|
Loading…
Reference in New Issue