forked from pEp.foundation/internet-drafts
remove the MEDUP requirements, specifically for distributed private messaging applications
parent
8247bab563
commit
3bc84357dc
|
|
@ -117,66 +117,6 @@ latter cases).
|
|||
* 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):
|
||||
|
||||
|
|
@ -213,9 +153,9 @@ instant messaging {{Unger}} {{Ermoshina}} {{Clark}}.
|
|||
* 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
|
||||
|
||||
# Threat Analyses and requirements
|
||||
|
||||
This section describes a set of possible threats. Note that not all
|
||||
threats can be addressed, due to conflicting requirements.
|
||||
|
|
@ -405,310 +345,6 @@ 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
|
||||
|
||||
|
||||
|
||||
<!-- =================================================================== -->
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,19 +0,0 @@
|
|||
Diaz:
|
||||
# target:
|
||||
title: Towards Measuring Anonymity
|
||||
author:
|
||||
-
|
||||
name: Claudia Diaz
|
||||
ins: C. Diaz
|
||||
-
|
||||
name: Stefaan Seys
|
||||
ins: St. Seys
|
||||
-
|
||||
name: Joris Claessens
|
||||
ins: J. Claessens
|
||||
-
|
||||
name: Bart Preneel
|
||||
ins: B. Preneel
|
||||
date: 2002
|
||||
seriesinfo:
|
||||
PET: Privacy Enhancing Technologies, Second International Workshop, San Francisco, CA, USA, April 14-15, 2002, Revised Papers, pp. 54-68
|
||||
Loading…
Reference in New Issue