Browse Source

Updated references to review

master
Bernie Hoeneisen 3 years ago
parent
commit
ba0992c7b7
2 changed files with 113 additions and 42 deletions
  1. +20
    -5
      medup-requirements/review/draft-symeonidis-medup-requirements-00-pre20190624.html
  2. +93
    -37
      medup-requirements/review/draft-symeonidis-medup-requirements-00-pre20190624.txt

+ 20
- 5
medup-requirements/review/draft-symeonidis-medup-requirements-00-pre20190624.html View File

@ -702,7 +702,7 @@
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#basic-functional-requirements" id="basic-functional-requirements">Basic Functional Requirements</a>
</h1>
<p id="rfc.section.3.p.1">This section outlines the functional requirements.</p>
<p id="rfc.section.3.p.1">This section outlines the functional requirements. We follow the requirements extracted from the literature on private emails and instant messaging <a href="#Unger" class="xref">[Unger]</a>.</p>
<p></p>
<ul>
@ -761,7 +761,7 @@
<h1 id="rfc.section.6.1.2">
<a href="#rfc.section.6.1.2">6.1.2.</a> <a href="#information-disclosure-and-confidentiality" id="information-disclosure-and-confidentiality">Information Disclosure and Confidentiality</a>
</h1>
<p id="rfc.section.6.1.2.p.1">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. Therefore, confidentiality of messages exchanged in the system should be guaranteed with the use of encryption schemes such as symmetric, asymmetric, or homomorphic encryption.</p>
<p id="rfc.section.6.1.2.p.1">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 <a href="#Tor" class="xref">[Tor]</a>. Therefore, confidentiality of messages exchanged in the system should be guaranteed with the use of encryption schemes such as symmetric, asymmetric, or homomorphic encryption.</p>
<h1 id="rfc.section.6.1.3">
<a href="#rfc.section.6.1.3">6.1.3.</a> <a href="#tampering-with-data-and-data-authentication" id="tampering-with-data-and-data-authentication">Tampering With Data and Data Authentication</a>
</h1>
@ -776,7 +776,7 @@
<h1 id="rfc.section.6.2.1">
<a href="#rfc.section.6.2.1">6.2.1.</a> <a href="#identifiability-anonymity" id="identifiability-anonymity">Identifiability &#8211; Anonymity</a>
</h1>
<p id="rfc.section.6.2.1.p.1">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 &#8220;Anonymity of a subject from an attacker&#8217;s perspective means that the attacker cannot sufficiently identify the subject within a set of subjects, the anonymity set&#8221;. 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. 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.</p>
<p id="rfc.section.6.2.1.p.1">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 &#8220;Anonymity of a subject from an attacker&#8217;s perspective means that the attacker cannot sufficiently identify the subject within a set of subjects, the anonymity set&#8221; <a href="#Pfitzmann" class="xref">[Pfitzmann]</a>. 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 <a href="#Diaz" class="xref">[Diaz]</a>. 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.</p>
<h1 id="rfc.section.6.2.2">
<a href="#rfc.section.6.2.2">6.2.2.</a> <a href="#linkability-unlinkability" id="linkability-unlinkability">Linkability &#8211; Unlinkability</a>
</h1>
@ -784,7 +784,7 @@
<h1 id="rfc.section.6.2.3">
<a href="#rfc.section.6.2.3">6.2.3.</a> <a href="#detectability-and-observatility-unditectability" id="detectability-and-observatility-unditectability">Detectability and observatility &#8211; Unditectability</a>
</h1>
<p id="rfc.section.6.2.3.p.1">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 &#8220;Undetectability of an item of interest (IOI) from an attacker&#8217;s perspective means that the attacker cannot sufficiently distinguish whether it exists or not.&#8221;. Undetectability of IOIs can be guaranteed with the use of cryptographic schemes such as Mix-nets and obfuscation mechanisms such as dummy traffic.</p>
<p id="rfc.section.6.2.3.p.1">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 &#8220;Undetectability of an item of interest (IOI) from an attacker&#8217;s perspective means that the attacker cannot sufficiently distinguish whether it exists or not.&#8221; <a href="#Pfitzmann" class="xref">[Pfitzmann]</a>. Undetectability of IOIs can be guaranteed with the use of cryptographic schemes such as Mix-nets and obfuscation mechanisms such as dummy traffic.</p>
<h1 id="rfc.section.6.3">
<a href="#rfc.section.6.3">6.3.</a> <a href="#information-disclosure-confidentiality" id="information-disclosure-confidentiality">Information disclosure &#8211; confidentiality</a>
</h1>
@ -1043,6 +1043,16 @@
<a href="#rfc.references.1">13.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="Diaz">[Diaz]</b></td>
<td class="top">
<a>Diaz, C.</a>, <a>Seys, St.</a>, <a>Claessens, J.</a> and <a>B. Preneel</a>, "<a>Towards Measuring Anonymity</a>", PET Privacy Enhancing Technologies, Second International Workshop, San Francisco, CA, USA, April 14-15, 2002, Revised Papers, pp. 54-68, 2002.</td>
</tr>
<tr>
<td class="reference"><b id="Pfitzmann">[Pfitzmann]</b></td>
<td class="top">
<a>Pfitzmann, A.</a> and <a>M. Hansen</a>, "<a href="https://nyuscholars.nyu.edu/en/publications/sok-secure-messaging">A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management</a>", 2010.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
@ -1058,7 +1068,12 @@
<a>Dukhovni, V.</a>, "<a href="https://tools.ietf.org/html/rfc7435">Opportunistic Security: Some Protection Most of the Time</a>", RFC 7435, DOI 10.17487/RFC7435, December 2014.</td>
</tr>
<tr>
<td class="reference"><b id="Unger.SoK">[Unger.SoK]</b></td>
<td class="reference"><b id="Tor">[Tor]</b></td>
<td class="top">
<a>Project, T.</a>, "<a href="https://blog.torproject.org/one-cell-enough-break-tors-anonymity/">One cell is enough to break Tor's anonymity</a>", June 2019.</td>
</tr>
<tr>
<td class="reference"><b id="Unger">[Unger]</b></td>
<td class="top">
<a>Unger, N.</a>, <a>Dechand, S.</a>, <a>Bonneau, J.</a>, <a>Fahl, S.</a>, <a>Perl, H.</a>, <a>Goldberg, I.</a> and <a>M. Smith</a>, "<a href="https://nyuscholars.nyu.edu/en/publications/sok-secure-messaging">SoK: Secure Messaging</a>", IEEE Proceedings - 2015 IEEE Symposium on Security and Privacy, SP 2015, pages 232-249, July 2015.</td>
</tr>


+ 93
- 37
medup-requirements/review/draft-symeonidis-medup-requirements-00-pre20190624.txt View File

@ -117,7 +117,7 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 16
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 17
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
@ -319,7 +319,9 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
3. Basic Functional Requirements
This section outlines the functional requirements.
This section outlines the functional requirements. We follow the
requirements extracted from the literature on private emails and
instant messaging [Unger].
o Message: send and receive message(s)
@ -331,8 +333,6 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 6]
Internet-Draft MEDUP Motivation and Requirements June 2019
@ -419,9 +419,9 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
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. Therefore, confidentiality of
messages exchanged in the system should be guaranteed with the use of
encryption schemes such as symmetric, asymmetric, or homomorphic
end-to-end communication systems [Tor]. Therefore, confidentiality
of messages exchanged in the system should be guaranteed with the use
of encryption schemes such as symmetric, asymmetric, or homomorphic
encryption.
6.1.3. Tampering With Data and Data Authentication
@ -482,13 +482,14 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
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". 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. 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.
anonymity set" [Pfitzmann]. 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 [Diaz]. 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.
6.2.2. Linkability - Unlinkability
@ -497,7 +498,6 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
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,
@ -506,6 +506,7 @@ Symeonidis & Hoeneisen Expires December 26, 2019 [Page 9]
Internet-Draft MEDUP Motivation and Requirements June 2019
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.
@ -521,9 +522,9 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
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.".
Undetectability of IOIs can be guaranteed with the use of
cryptographic schemes such as Mix-nets and obfuscation mechanisms
attacker cannot sufficiently distinguish whether it exists or not."
[Pfitzmann]. Undetectability of IOIs can be guaranteed with the use
of cryptographic schemes such as Mix-nets and obfuscation mechanisms
such as dummy traffic.
6.3. Information disclosure - confidentiality
@ -556,7 +557,6 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 10]
Internet-Draft MEDUP Motivation and Requirements June 2019
@ -827,11 +827,11 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[Diaz] Diaz, C., Seys, St., Claessens, J., and B. Preneel,
"Towards Measuring Anonymity", PET Privacy Enhancing
Technologies, Second International Workshop, San
Francisco, CA, USA, April 14-15, 2002, Revised Papers, pp.
54-68, 2002.
@ -842,6 +842,19 @@ Symeonidis & Hoeneisen Expires December 26, 2019 [Page 15]
Internet-Draft MEDUP Motivation and Requirements June 2019
[Pfitzmann]
Pfitzmann, A. and M. Hansen, "A terminology for talking
about privacy by data minimization: Anonymity,
unlinkability, undetectability, unobservability,
pseudonymity, and identity management", 2010,
<https://nyuscholars.nyu.edu/en/publications/
sok-secure-messaging>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
@ -850,8 +863,11 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[Unger.SoK]
Unger, N., Dechand, S., Bonneau, J., Fahl, S., Perl, H.,
[Tor] Project, T., "One cell is enough to break Tor's
anonymity", June 2019, <https://blog.torproject.org/
one-cell-enough-break-tors-anonymity/>.
[Unger] Unger, N., Dechand, S., Bonneau, J., Fahl, S., Perl, H.,
Goldberg, I., and M. Smith, "SoK: Secure Messaging",
IEEE Proceedings - 2015 IEEE Symposium on Security and
Privacy, SP 2015, pages 232-249, July 2015,
@ -871,6 +887,17 @@ Internet-Draft MEDUP Motivation and Requirements June 2019
Considerations", draft-birk-pep-trustwords-03 (work in
progress), March 2019.
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 16]
Internet-Draft MEDUP Motivation and Requirements June 2019
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
@ -888,16 +915,6 @@ Appendix A. Document Changelog
* Initial version
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 16]
Internet-Draft MEDUP Motivation and Requirements June 2019
Appendix B. Open Issues
[[ RFC Editor: This section should be empty and is to be removed
@ -925,6 +942,18 @@ Authors' Addresses
URI: https://wwwen.uni.lu/snt/people/iraklis_symeonidis
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 17]
Internet-Draft MEDUP Motivation and Requirements June 2019
Bernie Hoeneisen
Ucom Standards Track Solutions GmbH
CH-8046 Zuerich
@ -949,4 +978,31 @@ Authors' Addresses
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 17]
Symeonidis & Hoeneisen Expires December 26, 2019 [Page 18]

Loading…
Cancel
Save