intermediate state, mostly worked on use cases

master
Bernie Hoeneisen 4 years ago
parent 15f4444856
commit dd22f475af

@ -15,12 +15,12 @@ $(DRAFT).xml: $(NAME).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/ed-keysync.mkd \
# ../shared/references/isoc-btn.mkd \
# ../shared/references/implementation-status.mkd \
# ../shared/text-blocks/implementation-status.mkd \
# ../shared/ascii-arts/pep_id_system.mkd \
# ../shared/ascii-arts/basic-msg-flow.mkd \
# to match backslash at the end of the previous line
kramdown-rfc2629 $(NAME).mkd > $(DRAFT).xml

@ -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

Loading…
Cancel
Save