Browse Source

addes some words on autocrypt, references and clean-up (minor editorials)

master
Bernie Hoeneisen 3 years ago
parent
commit
36bed5277e
2 changed files with 220 additions and 50 deletions
  1. +192
    -50
      medup-requirements/draft-symeonidis-medup-requirements.mkd
  2. +28
    -0
      shared/references/unger-sok.mkd

+ 192
- 50
medup-requirements/draft-symeonidis-medup-requirements.mkd View File

@ -16,9 +16,11 @@ author:
normative:
RFC4949:
RFC7435:
{::include ../shared/references/unger-sok.mkd}
informative:
# RFC4880:
RFC4880:
# RFC6973:
# RFC7258:
# RFC7942:
@ -27,12 +29,13 @@ informative:
# I-D.marques-pep-email:
I-D.birk-pep-trustwords:
# I-D.marques-pep-rating:
I-D.marques-pep-handshake:
# I-D.marques-pep-handshake:
# {::include ../shared/references/ed-keysync.mkd}
# {::include ../shared/references/isoc-btn.mkd}
# {::include ../shared/references/implementation-status.mkd}
--- abstract
{{RFC8280}} has identified and documented important principles in such
@ -64,7 +67,7 @@ This document covers analysis of threats and requirements.
{::include ../shared/text-blocks/terms-intro.mkd}
{::include ../shared/text-blocks/handshake.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}
@ -86,6 +89,9 @@ This document covers analysis of threats and requirements.
* 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
@ -93,6 +99,7 @@ Privacy) {{I-D.birk-pep}}:
{::include ../shared/ascii-arts/basic-msg-flow.mkd}
<vspace blankLines="10" />
<!--
@ -118,16 +125,30 @@ pEp is supposed to provide Privacy by Default at least for message
content. In addition, pEp is providing meta data protection. pEp is
meant to be used in already existing messaging solutions.
And pEp is supposed to provide technical data protection by
implementing mix network capabilities.
Additionally, there are use cases for enterprise environments, where
e.g. some instance at the enterprise may need to look into the
messages. Reasons for this include compliance requirements or virus /
malware checking \[\[TODO: Decide whether those are covered herein\]\]
-->
malware checking
\[\[ TODO: Decide whether enterprise requirements will be covered
herein \]\]
### Autocrypt
The Autocrypt approach is also a known project following the above
mentioned principles, though - compared to pEp (cf. {{pEp}}) - the
goals slightly differ, for example regarding support of
legacy PGP {{RFC4880}} implementations.
More information on Autocypt can be found on:
https://autocrypt.org/background.html
\[\[ TODO: Input from autocrypt group \]\]
# Basic Functional Requirements
@ -137,6 +158,8 @@ This section outlines the functional requirements.
* Multi-device support: synchronisation across multiple devices
* Group messaging: communication of more than 2 users
\[\[ TODO: Add more text on Group Messaging requirements. \]\]
# Threat Analyses
@ -144,13 +167,13 @@ This section describes a set of possible threats. Note that not all threats
can be addressed, due to conflicting requirements.
## Establish Evaluation Criteria For:
## Establish Evaluation Criteria for:
* security and privacy requirements
* Security and privacy requirements
* usability (little work on usability and trust establishment)
* Usability (little work on usability and trust establishment)
* adoption implications
* Adoption implications
## Focus Areas (Design Challenges):
@ -162,73 +185,190 @@ can be addressed, due to conflicting requirements.
* Transport privacy: no human interaction
<!-- =================================================================== -->
# System model
## Entities
### Users: Sender and receiver(s)
There are the communicating parties such as the sender and receiver of messages.
# System Model
### Messaging operators and network nodes
Are the servers and network nodes who are responsible for message delivery and synchronization.
## Entities
### Third parties
It is any other entity who is interacting with the system.
* Users: Sender and receiver(s)
# Problem areas
There are the communicating parties such as the sender and receiver of messages.
## Security Threats and Requirements
* Messaging operators and network nodes
### Spoofing and entity authentication
An adversary can spoof and impersonate a profile of a user. It may attempt to send or receive a message on behalf of a legitimate user. An adversary can be a user of the system gaining access as an imposter sending or receiving a message. For example, an adversary can impersonate a valid sender of a message and send it on their behalf. The capabilities of an adversary are usually local controlling one entity or a set of entities, in the sense that each spoofed identity will be used to communicate with different end users. To mitigate spoofing threats is essential to have entity authentication mechanisms safeguarding that a user is the legitimate owner of a messaging service account. For example, it can prove that he/she knows something such as passwords, posses something such as public key and have specific features such as biometrics.
Are the servers and network nodes who are responsible for message delivery and synchronization.
### Information disclosure and confidentiality
* Third parties
An adversary aims to retrieve and disclose information about the content of a message. It can attempt to perform a man-in-the-middle attack (MitM) eavesdropping and forwarding messages as an intermediary between the communicating users. For example, an adversary can try to position itself between two communicating parties such as the messaging server and remain undetectable collecting information transmitted to the intended users. The capabilities of an adversary can be from local controlling one point of the communication channel such as an entity or a communication link of the network. It can also be a global adversary controlling several entities and communication links of the channel, gaining the capability of correlating traffic such as in timing attacks even for end-to-end communication systems~\cite{torwebsite:timing-attacks}. Therefore, \textbf{confidentiality} of messages exchanged in the system should be guaranteed with the use of encryption schemes such as symmetric, asymmetric, or homomorphic encryption.
It is any other entity who is interacting with the system.
### Tampering with data and Data authentication
# Problem Areas
An adversary can tamper with the messages aiming to modify the information stored or 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. It can be anyone but the users who are communicating such as the message operators, the network node, and third parties. The capabilities of an adversary can be local controlling an entity that can alter messages usually performing MitM attack for an encrypted channel. Therefore, no honest party should accept a message that was modified in transit. Data authentication of messages needs to be guaranteed such as with the use of MAC algorithms and digital signatures.
## Security Threats and Requirements
### Repudiation and accountability (non-repudiation)
### Spoofing and Entity Authentication
An adversary can spoof and impersonate a profile of a user. It may
attempt to send or receive a message on behalf of a legitimate
user. An adversary can be a user of the system gaining access as an
imposter sending or receiving a message. For example, an adversary can
impersonate a valid sender of a message and send it on their
behalf. The capabilities of an adversary are usually local controlling
one entity or a set of entities, in the sense that each spoofed
identity will be used to communicate with different end users. To
mitigate spoofing threats is essential to have entity authentication
mechanisms safeguarding that a user is the legitimate owner of a
messaging service account. For example, it can prove that he/she knows
something such as passwords, posses something such as public key and
have specific features such as biometrics.
### Information Disclosure and Confidentiality
An adversary aims to retrieve and disclose information about the
content of a message. It can attempt to perform a man-in-the-middle
attack (MitM) eavesdropping and forwarding messages as an intermediary
between the communicating users. For example, an adversary can try to
position itself between two communicating parties such as the
messaging server and remain undetectable collecting information
transmitted to the intended users. The capabilities of an adversary
can be from local controlling one point of the communication channel
such as an entity or a communication link of the network. It can also
be a global adversary controlling several entities and communication
links of the channel, gaining the capability of correlating traffic
such as in timing attacks even for end-to-end communication
systems<!-- ~\cite{torwebsite:timing-attacks} -->. Therefore,
confidentiality of messages exchanged in the system should be
guaranteed with the use of encryption schemes such as symmetric,
asymmetric, or homomorphic encryption.
### Tampering With Data and Data Authentication
An adversary can tamper with the messages aiming to modify the
information stored or 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. It can be
anyone but the users who are communicating such as the message
operators, the network node, and third parties. The capabilities of an
adversary can be local controlling an entity that can alter messages
usually performing MitM attack for an encrypted channel. Therefore, no
honest party should accept a message that was modified in transit.
Data authentication of messages needs to be guaranteed such as with
the use of MAC algorithms and digital signatures.
### Repudiation and Accountability (Non-Repudiation)
An adversary can repudiate an email sent or received by providing
falsified information about the status of the message to users of the
system. For instance, an adversary may attempt to state 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 be of origin, submission,
delivery, and receipt providing proof of actions performed to the
intended recipient. It can be achieved with the use of cryptographic
schemes such as digital signatures and audit trails such as
timestamps.
An adversary can repudiate an email sent or received by providing falsified information about the status of the message to users of the system. For instance, an adversary may attempt to state 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 be of origin, submission, delivery, and receipt providing proof of actions performed to the intended recipient. It 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
An adversary can identify a specific user associated with an Items of Interest (IOI), i.e., an ID of a subject, a message sent, and an action performed. Identifiability is the state under which a specific user can be identified from a set of users defined as the identifiability set. For instance, it may identify the sender of a message by examining the headers of an email exchanged within a system. An adversary can be anyone but the users who are communicating such as the message operators, the network node or third parties. To mitigate identifiability threats, the anonymity of users must be guaranteed. It is defined as the ``Anonymity of a subject from an attacker’s perspective means that the attacker cannot sufficiently identify the subject within a set of subjects, the anonymity set''~\cite{pfitzmann2010terminology}. Essentially, to enable anonymity, there is always need to be a set of possible subjects such that for an adversary the communicating user can be equally likely of any other user in the set~\cite{DBLP:conf/pet/DiazSCP02}. Thus, an adversary cannot deduce who is the originator 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.
An adversary can identify a specific user associated with an Items of
Interest (IOI), i.e., an ID of a subject, a message sent, and an
action performed. Identifiability is the state under which a specific
user can be identified from a set of users defined as the
identifiability set. For instance, it may identify the sender of a
message by examining the headers of an email exchanged within a
system. An adversary can be anyone but the users who are communicating
such as the message operators, the network node or third parties. To
mitigate identifiability threats, the anonymity of users must be
guaranteed. It is defined as the "Anonymity of a subject from an
attacker’s perspective means that the attacker cannot sufficiently
identify the subject within a set of subjects, the anonymity set"<!--
~\cite{pfitzmann2010terminology} -->. Essentially, to enable
anonymity, there is always need to be a set of possible subjects such
that for an adversary the communicating user can be equally likely of
any other user in the set<!-- ~\cite{DBLP:conf/pet/DiazSCP02}
-->. Thus, an adversary cannot deduce who is the originator 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
An adversary can sufficiently distinguish within the system, whether two or more Items of Interest (IOI) such as subjects, objects, messages, and actions are linked to the same user. For instance, an adversary can relate pseudonyms from messages exchanged and deduce whether it is the same user who sent the messages. It can be anyone but the users who are communicating such as the message operators, the network node, or third parties. Therefore, unlinkability of IOIs should be guaranteed with the use of pseudonyms and cryptographic schemes such as anonymous credentials.
An adversary can sufficiently distinguish within the system, whether
two or more Items of Interest (IOI) such as subjects, objects,
messages, and actions are linked to the same user. For instance, an
adversary can relate pseudonyms from messages exchanged and deduce
whether it is the same user who sent the messages. It can be anyone
but the users who are communicating such as the message operators, the
network node, or third parties. Therefore, unlinkability of IOIs
should be guaranteed with the use of pseudonyms and cryptographic
schemes such as anonymous credentials.
### Detectability and observatility -- Unditectability
An adversary can sufficiently detect an IOI such as messages exchanged within the system from random noise. For instance, an adversary can detect a specific IOI when a user is sending a message from a set of communicating users. An adversary can be anyone but the users who are communicating such as the message operators, the network node or third parties. In contrast to anonymity and unlinkability, where the relationship from an IOI to a user is preserved, undetectability is defined as ``Undetectability of an item of interest (IOI) from an attacker’s perspective means that the attacker cannot sufficiently distinguish whether it exists or not.''~\cite{pfitzmann2010terminology}. Undetectability of IOIs can be guaranteed with the use of cryptographic schemes such as Mix-nets and obfuscation mechanisms such as dummy traffic.
An adversary can sufficiently detect an IOI such as messages exchanged
within the system from random noise. For instance, an adversary can
detect a specific IOI when a user is sending a message from a set of
communicating users. An adversary can be anyone but the users who are
communicating such as the message operators, the network node or third
parties. In contrast to anonymity and unlinkability, where the
relationship from an IOI to a user is preserved, undetectability is
defined as "Undetectability of an item of interest (IOI) from an
attacker’s perspective means that the attacker cannot sufficiently
distinguish whether it exists or not."<!--
~\cite{pfitzmann2010terminology} -->. Undetectability of IOIs can be
guaranteed with the use of cryptographic schemes such as Mix-nets and
obfuscation mechanisms such as dummy traffic.
## Information disclosure -- confidentiality
An adversary can disclose information exchanged within the system about users. It can perform a MitM aiming to learn the contents of a message the metadata information such as with whom someone is communicating with and with which frequency. It can be anyone but the users who are communicating such as the messaging server, and the network nodes. The capabilities of an adversary can be local controlling one entity or channel of the network to a global adversary which can control several entities and communication links. Confidentiality of messages, together with security, needs to be guaranteed with the use of cryptographic operations such as secret sharing, symmetric, asymmetric, or homomorphic encryption.
An adversary can disclose information exchanged within the system
about users. It can perform a MitM aiming to learn the contents of a
message the metadata information such as with whom someone is
communicating with and with which frequency. It can be anyone but the
users who are communicating such as the messaging server, and the
network nodes. The capabilities of an adversary can be local
controlling one entity or channel of the network to a global adversary
which can control several entities and communication
links. Confidentiality of messages, together with security, needs to
be guaranteed with the use of cryptographic operations such as secret
sharing, symmetric, asymmetric, or homomorphic encryption.
## Non-repudiation and deniability
In contrast to security, non-repudiation can be a threat to a user's privacy for messaging systems. An adversary may attempt to collect evidence exchanged in the system aiming to prove to others that a specific user is the originator of a specific message. That can be problematic for users as whistle-blowers in countries where censorship is a daily routine and to countries where human life can be at stake. Therefore plausible deniability, unlike non-repudiation, must be guaranteed where the system guarantees that an adversary cannot confirm either contradict that a specific user has sent a message. Deniability can be guaranteed with the use of cryptographic schemes such as off-the-record messages.
In contrast to security, non-repudiation can be a threat to a user's
privacy for messaging systems. An adversary may attempt to collect
evidence exchanged in the system aiming to prove to others that a
specific user is the originator of a specific message. That can be
problematic for users as whistle-blowers in countries where censorship
is a daily routine and to countries where human life can be at
stake. Therefore plausible deniability, unlike non-repudiation, must
be guaranteed where the system guarantees that an adversary cannot
confirm either contradict that a specific user has sent a
message. Deniability can be guaranteed with the use of cryptographic
schemes such as off-the-record messages.
<!-- =================================================================== -->
# Specific security and privacy requirements
# Specific Security and Privacy Requirements
## Messages Exchange
### Send Message
* Send encrypted and signed message to another peer
* Send unencrypted and unsigned message to another peer
@ -236,6 +376,8 @@ In contrast to security, non-repudiation can be a threat to a user's privacy for
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 not signed message from another peer
@ -257,7 +399,7 @@ In contrast to security, non-repudiation can be a threat to a user's privacy for
* 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 peer is revoked (cf. {{key-management}}, Key Reset)
* Trust of a public key is synchronized among different devices of the
same user
@ -275,7 +417,7 @@ In contrast to security, non-repudiation can be a threat to a user's privacy for
* Public Key received by a peer is stored locally
* Key pair is declared invalid and other peers are informed (key reset)
* Key pair is declared invalid and other peers are informed (Key Reset)
* Public Key is marked invalid after receiving a key reset message
@ -309,7 +451,7 @@ group devices of the same user mutually grant authentication.
* Remove other device from device group
## Identity management
## Identity Management
* All involved parties share the same identity system
@ -327,7 +469,7 @@ group devices of the same user mutually grant authentication.
# Subcases
\[\[ TODO: Do we need this section at all? \]\]
<!-- Do we need this section at all? -->
## Interaction States
@ -431,21 +573,22 @@ several bilateral interactions.
<!-- =================================================================== -->
# Security Considerations
lorem ipsum
Relevant security considerations are outlined in {{security-threats-and-requirements}}.
# Privacy Considerations
lorem ipsum
Relevant privacy considerations are outlined in {{privacy-threats-and-requirements}}.
# IANA Considerations
lorem ipsum
This document requests no action from IANA.
\[\[ RFC Editor: This section may be removed before publication. \]\]
# Acknowledgements
@ -474,10 +617,9 @@ lorem ipsum
* Add references to used materials (in particular threat analyses part)
References
* Get content from Autocrypt ({{autocrypt}})
1. Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fahl, Henning
Perl, Ian Goldberg, Matthew Smith SoK: Secure Messaging. pp:232-249
2015 IEEE Symposium on Security and Privacy
* Add more text on Group Messaging requirements
2. Clark et al. ....
* Decide on whether or not "enterprise requirement" will go to this
document

+ 28
- 0
shared/references/unger-sok.mkd View File

@ -0,0 +1,28 @@
Unger.SoK:
target: https://nyuscholars.nyu.edu/en/publications/sok-secure-messaging
title: "SoK: Secure Messaging"
author:
-
name: Nik Unger
ins: N. Unger
-
name: Sergej Dechand
ins: S. Dechand
-
name: Joseph Bonneau
ins: J. Bonneau
-
name: Sascha Fahl
ins: S. Fahl
-
name: Henning Perl
ins: H. Perl
-
name: Ian Goldberg
ins: I. Goldberg
-
name: Matthew Smith
ins: M. Smith
date: 2015-07
seriesinfo:
IEEE: Proceedings - 2015 IEEE Symposium on Security and Privacy, SP 2015, pages 232-249

Loading…
Cancel
Save