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

remove the MEDUP requirements, specifically for distributed private messaging applications

master
iraklis 3 years ago
parent
8247bab563
commit
3bc84357dc
2 changed files with 2 additions and 385 deletions
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +2
    -366
      pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd
  2. +0
    -19
      shared/references/diaz-measuring-anonymity.mkd

+ 2
- 366
pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd View File

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


+ 0
- 19
shared/references/diaz-measuring-anonymity.mkd View File

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

Write Preview
Loading…
Cancel
Save