|
|
|
@ -11,7 +11,7 @@ pi: [toc, sortrefs, symrefs, comments]
|
|
|
|
|
|
|
|
|
|
author:
|
|
|
|
|
{::include ../shared/author_tags/iraklis_symeonidis.mkd}
|
|
|
|
|
# {::include ../shared/author_tags/bernie_hoeneisen.mkd}
|
|
|
|
|
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
|
|
|
|
|
|
|
|
|
|
normative:
|
|
|
|
|
RFC2119:
|
|
|
|
@ -24,6 +24,7 @@ informative:
|
|
|
|
|
# RFC7258:
|
|
|
|
|
# RFC7942:
|
|
|
|
|
RFC8280:
|
|
|
|
|
I-D.birk-pep:
|
|
|
|
|
# I-D.marques-pep-email:
|
|
|
|
|
I-D.birk-pep-trustwords:
|
|
|
|
|
# I-D.marques-pep-rating:
|
|
|
|
@ -40,6 +41,8 @@ as Data Minimization, End-to-End and Interoperability in order to
|
|
|
|
|
enable access to Human Rights. While (partial) implementations of
|
|
|
|
|
these concepts are already available, today's applications widely lack
|
|
|
|
|
Privacy support that ordinary users can easily handle.
|
|
|
|
|
This document covers use cases, anaysis of threats and requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--- middle
|
|
|
|
|
|
|
|
|
@ -52,9 +55,11 @@ these concepts are already available, today's applications widely lack
|
|
|
|
|
Privacy support that ordinary users can easily handle.
|
|
|
|
|
|
|
|
|
|
In MEDUP these issues are addressed based on Opportunistic Security
|
|
|
|
|
(RFC 7435) principles.
|
|
|
|
|
{{RFC7435}} principles.
|
|
|
|
|
|
|
|
|
|
This document describes the use cases, contains an anaysis of threats
|
|
|
|
|
and deduces the requirements.
|
|
|
|
|
|
|
|
|
|
blabla
|
|
|
|
|
|
|
|
|
|
# Terms
|
|
|
|
|
|
|
|
|
@ -65,33 +70,154 @@ blabla
|
|
|
|
|
{::include ../shared/text-blocks/mitm.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Motivation
|
|
|
|
|
# Movitation and Background
|
|
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
|
|
|
|
|
The basic model consists of three different interaction states, i.e.:
|
|
|
|
|
|
|
|
|
|
1. Both peers have got no public key of each other, no trust possible
|
|
|
|
|
|
|
|
|
|
2. Only one peer has got the public key of the other peer, no trust
|
|
|
|
|
|
|
|
|
|
3. Only one peer has got the public key of the other peer, trusts the public key
|
|
|
|
|
|
|
|
|
|
4. Both peers have got the public key of each other, no trust
|
|
|
|
|
|
|
|
|
|
5. Both peers have got the public key of each other, only one peer
|
|
|
|
|
trusts the other peer's public key
|
|
|
|
|
|
|
|
|
|
6. Both peers have got the public key of each other, both peers trust
|
|
|
|
|
each others 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 simplicfied 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 behaviour.
|
|
|
|
|
|
|
|
|
|
Note: As one peer may have several keys or if group conversations are
|
|
|
|
|
involved, thing will get more complex. For the time being, we focus on
|
|
|
|
|
bilateral interactions, whereas group interactions are split up into
|
|
|
|
|
several bilateral interactions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Use Cases (Functional Requirements)
|
|
|
|
|
|
|
|
|
|
## Messages Exchange
|
|
|
|
|
|
|
|
|
|
* Peer's Public Key not available:
|
|
|
|
|
* Interaction States 1, 2a, and 3a
|
|
|
|
|
* Send message Unencrypted (optionally Signed)
|
|
|
|
|
|
|
|
|
|
* Peer's Public Key available:
|
|
|
|
|
* Interaction States 2b, 3b, 4, 5a, 5b, 6
|
|
|
|
|
* Send message Encrypted and Signed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Trust Management
|
|
|
|
|
|
|
|
|
|
* Peer's Public Key not available:
|
|
|
|
|
* Interaction States 1, 2a, and 3a
|
|
|
|
|
* No trust can be established
|
|
|
|
|
|
|
|
|
|
* Peer's Public Key available, but not trusted:
|
|
|
|
|
* Interaction States 2b, 4, 5a
|
|
|
|
|
* Trust may be established by using fingerprints
|
|
|
|
|
* Interaction States 4, 5a
|
|
|
|
|
* Trust may be established by using trustwords (cf. {{I-D.marques-pep-handshake}})
|
|
|
|
|
|
|
|
|
|
* Peer's Public Key available and trusted
|
|
|
|
|
* Interaction States 3b, 5b, 6
|
|
|
|
|
|
|
|
|
|
* Trust of a peer is revoked
|
|
|
|
|
|
|
|
|
|
* Trust is synchronized among different devices of the same user
|
|
|
|
|
|
|
|
|
|
## Threats
|
|
|
|
|
|
|
|
|
|
blabla
|
|
|
|
|
## Key Management
|
|
|
|
|
|
|
|
|
|
*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Threat Anlyses
|
|
|
|
|
|
|
|
|
|
## Threat Model
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Privacy Threats
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Security Threats
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Requirements
|
|
|
|
|
|
|
|
|
|
## Functional Requirements
|
|
|
|
|
|
|
|
|
|
blabla
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Whatever Requirements
|
|
|
|
|
## Privacy Requirements
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Security Requirements
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
blabla
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Security Considerations
|
|
|
|
|
|
|
|
|
|
blabla
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Privacy Considerations
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# IANA Considerations
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Acknowledgements
|
|
|
|
|
|
|
|
|
|
# Acknowledgments
|
|
|
|
|
|
|
|
|
|
The authors would like to thank the following people who have provided
|
|
|
|
|
feedback or significant contributions to the development of this
|
|
|
|
|
document: Forename Surname, Forename2 Surname2, ...
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
--- back
|
|
|
|
|
|
|
|
|
|
# Document Changelog
|
|
|
|
@ -106,4 +232,5 @@ document: Forename Surname, Forename2 Surname2, ...
|
|
|
|
|
\[\[ RFC Editor: This section should be empty and is to be removed
|
|
|
|
|
before publication \]\]
|
|
|
|
|
|
|
|
|
|
* Fill with relevant text
|
|
|
|
|
* lorem ipsum
|
|
|
|
|
|
|
|
|
|