p≡p I-Ds (IETF Internet-Drafts)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
internet-drafts/medup-requirements/review/draft-symeonidis-medup-requ...

1178 lines
53 KiB

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Motivation and Requirements for Decentralized Usable Privacy</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Language">
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terms">
<link href="#rfc.section.2" rel="Chapter" title="2 Motivation and Background">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Objectives">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Known Implementations">
<link href="#rfc.section.2.2.1" rel="Chapter" title="2.2.1 Pretty Easy Privacy (pEp)">
<link href="#rfc.section.2.2.2" rel="Chapter" title="2.2.2 Autocrypt">
<link href="#rfc.section.3" rel="Chapter" title="3 Basic Functional Requirements">
<link href="#rfc.section.4" rel="Chapter" title="4 Threat Analyses">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Establish Evaluation Criteria for:">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Focus Areas (Design Challenges):">
<link href="#rfc.section.5" rel="Chapter" title="5 System Model">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Entities">
<link href="#rfc.section.6" rel="Chapter" title="6 Problem Areas">
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Security Threats and Requirements">
<link href="#rfc.section.6.1.1" rel="Chapter" title="6.1.1 Spoofing and Entity Authentication">
<link href="#rfc.section.6.1.2" rel="Chapter" title="6.1.2 Information Disclosure and Confidentiality">
<link href="#rfc.section.6.1.3" rel="Chapter" title="6.1.3 Tampering With Data and Data Authentication">
<link href="#rfc.section.6.1.4" rel="Chapter" title="6.1.4 Repudiation and Accountability (Non-Repudiation)">
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Privacy Threats and Requirements">
<link href="#rfc.section.6.2.1" rel="Chapter" title="6.2.1 Identifiability &#8211; Anonymity">
<link href="#rfc.section.6.2.2" rel="Chapter" title="6.2.2 Linkability &#8211; Unlinkability">
<link href="#rfc.section.6.2.3" rel="Chapter" title="6.2.3 Detectability and observatility &#8211; Unditectability">
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Information disclosure &#8211; confidentiality">
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 Non-repudiation and deniability">
<link href="#rfc.section.7" rel="Chapter" title="7 Specific Security and Privacy Requirements">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Messages Exchange">
<link href="#rfc.section.7.1.1" rel="Chapter" title="7.1.1 Send Message">
<link href="#rfc.section.7.1.2" rel="Chapter" title="7.1.2 Receive Message">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Trust Management">
<link href="#rfc.section.7.3" rel="Chapter" title="7.3 Key Management">
<link href="#rfc.section.7.4" rel="Chapter" title="7.4 Synchronization Management">
<link href="#rfc.section.7.5" rel="Chapter" title="7.5 Identity Management">
<link href="#rfc.section.7.6" rel="Chapter" title="7.6 User Interface">
<link href="#rfc.section.8" rel="Chapter" title="8 Subcases">
<link href="#rfc.section.8.1" rel="Chapter" title="8.1 Interaction States">
<link href="#rfc.section.8.2" rel="Chapter" title="8.2 Subcases for Sending Messages">
<link href="#rfc.section.8.3" rel="Chapter" title="8.3 Subcases for Receiving Messages">
<link href="#rfc.section.9" rel="Chapter" title="9 Security Considerations">
<link href="#rfc.section.10" rel="Chapter" title="10 Privacy Considerations">
<link href="#rfc.section.11" rel="Chapter" title="11 IANA Considerations">
<link href="#rfc.section.12" rel="Chapter" title="12 Acknowledgements">
<link href="#rfc.references" rel="Chapter" title="13 References">
<link href="#rfc.references.1" rel="Chapter" title="13.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="13.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Document Changelog">
<link href="#rfc.appendix.B" rel="Chapter" title="B Open Issues">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.9.6 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Symeonidis, I. and B. Hoeneisen" />
<meta name="dct.identifier" content="urn:ietf:id:draft-symeonidis-medup-requirements-00" />
<meta name="dct.issued" scheme="ISO8601" content="2019-06-24" />
<meta name="dct.abstract" content="" />
<meta name="description" content="" />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">I. Symeonidis</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">University of Luxembourg</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">B. Hoeneisen</td>
</tr>
<tr>
<td class="left">Expires: December 26, 2019</td>
<td class="right">Ucom.ch</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">June 24, 2019</td>
</tr>
</tbody>
</table>
<p class="title">Motivation and Requirements for Decentralized Usable Privacy<br />
<span class="filename">draft-symeonidis-medup-requirements-00</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p><a href="#RFC8280" class="xref">[RFC8280]</a> has identified and documented important principles in such 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&#8217;s applications widely lack Privacy support that ordinary users can easily handle. This document covers analysis of threats and requirements.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on December 26, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Requirements Language</a>
</li>
<li>1.2. <a href="#rfc.section.1.2">Terms</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Motivation and Background</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Objectives</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Known Implementations</a>
</li>
<ul><li>2.2.1. <a href="#rfc.section.2.2.1">Pretty Easy Privacy (pEp)</a>
</li>
<li>2.2.2. <a href="#rfc.section.2.2.2">Autocrypt</a>
</li>
</ul></ul><li>3. <a href="#rfc.section.3">Basic Functional Requirements</a>
</li>
<li>4. <a href="#rfc.section.4">Threat Analyses</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Establish Evaluation Criteria for:</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">Focus Areas (Design Challenges):</a>
</li>
</ul><li>5. <a href="#rfc.section.5">System Model</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Entities</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Problem Areas</a>
</li>
<ul><li>6.1. <a href="#rfc.section.6.1">Security Threats and Requirements</a>
</li>
<ul><li>6.1.1. <a href="#rfc.section.6.1.1">Spoofing and Entity Authentication</a>
</li>
<li>6.1.2. <a href="#rfc.section.6.1.2">Information Disclosure and Confidentiality</a>
</li>
<li>6.1.3. <a href="#rfc.section.6.1.3">Tampering With Data and Data Authentication</a>
</li>
<li>6.1.4. <a href="#rfc.section.6.1.4">Repudiation and Accountability (Non-Repudiation)</a>
</li>
</ul><li>6.2. <a href="#rfc.section.6.2">Privacy Threats and Requirements</a>
</li>
<ul><li>6.2.1. <a href="#rfc.section.6.2.1">Identifiability &#8211; Anonymity</a>
</li>
<li>6.2.2. <a href="#rfc.section.6.2.2">Linkability &#8211; Unlinkability</a>
</li>
<li>6.2.3. <a href="#rfc.section.6.2.3">Detectability and observatility &#8211; Unditectability</a>
</li>
</ul><li>6.3. <a href="#rfc.section.6.3">Information disclosure &#8211; confidentiality</a>
</li>
<li>6.4. <a href="#rfc.section.6.4">Non-repudiation and deniability</a>
</li>
</ul><li>7. <a href="#rfc.section.7">Specific Security and Privacy Requirements</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Messages Exchange</a>
</li>
<ul><li>7.1.1. <a href="#rfc.section.7.1.1">Send Message</a>
</li>
<li>7.1.2. <a href="#rfc.section.7.1.2">Receive Message</a>
</li>
</ul><li>7.2. <a href="#rfc.section.7.2">Trust Management</a>
</li>
<li>7.3. <a href="#rfc.section.7.3">Key Management</a>
</li>
<li>7.4. <a href="#rfc.section.7.4">Synchronization Management</a>
</li>
<li>7.5. <a href="#rfc.section.7.5">Identity Management</a>
</li>
<li>7.6. <a href="#rfc.section.7.6">User Interface</a>
</li>
</ul><li>8. <a href="#rfc.section.8">Subcases</a>
</li>
<ul><li>8.1. <a href="#rfc.section.8.1">Interaction States</a>
</li>
<li>8.2. <a href="#rfc.section.8.2">Subcases for Sending Messages</a>
</li>
<li>8.3. <a href="#rfc.section.8.3">Subcases for Receiving Messages</a>
</li>
</ul><li>9. <a href="#rfc.section.9">Security Considerations</a>
</li>
<li>10. <a href="#rfc.section.10">Privacy Considerations</a>
</li>
<li>11. <a href="#rfc.section.11">IANA Considerations</a>
</li>
<li>12. <a href="#rfc.section.12">Acknowledgements</a>
</li>
<li>13. <a href="#rfc.references">References</a>
</li>
<ul><li>13.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>13.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Document Changelog</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Open Issues</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p><a href="#RFC8280" class="xref">[RFC8280]</a> has identified and documented important principles in such 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&#8217;s applications widely lack Privacy support that ordinary users can easily handle.</p>
<p id="rfc.section.1.p.2">In MEDUP these issues are addressed based on Opportunistic Security <a href="#RFC7435" class="xref">[RFC7435]</a> principles.</p>
<p id="rfc.section.1.p.3">This document covers analysis of threats and requirements.</p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#requirements-language" id="requirements-language">Requirements Language</a>
</h1>
<p id="rfc.section.1.1.p.1">The key words &#8220;MUST&#8221;, &#8220;MUST NOT&#8221;, &#8220;REQUIRED&#8221;, &#8220;SHALL&#8221;, &#8220;SHALL NOT&#8221;, &#8220;SHOULD&#8221;, &#8220;SHOULD NOT&#8221;, &#8220;RECOMMENDED&#8221;, &#8220;MAY&#8221;, and &#8220;OPTIONAL&#8221; in this document are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> <a href="#terms" id="terms">Terms</a>
</h1>
<p id="rfc.section.1.2.p.1">The following terms are defined for the scope of this document:</p>
<p></p>
<ul>
<li>Trustwords: A scalar-to-word representation of 16-bit numbers (0 to 65535) to natural language words. When doing a Handshake, peers are shown combined Trustwords of both public keys involved to ease the comparison. <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a>
</li>
<li>Trust on First Use (TOFU): cf. <a href="#RFC7435" class="xref">[RFC7435]</a>
</li>
<li>Man-in-the-middle attack (MITM): cf. <a href="#RFC4949" class="xref">[RFC4949]</a>
</li>
</ul>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#motivation-and-background" id="motivation-and-background">Motivation and Background</a>
</h1>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#objectives" id="objectives">Objectives</a>
</h1>
<p></p>
<ul>
<li>An open standard for secure messaging requirements</li>
<li>Unified evaluation framework: unified goals and threat models</li>
<li>Common pitfalls</li>
<li>Future directions on requirements and technologies</li>
<li>Misleading products on the wild (EFF secure messaging scorecard)</li>
</ul>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#known-implementations" id="known-implementations">Known Implementations</a>
</h1>
<h1 id="rfc.section.2.2.1">
<a href="#rfc.section.2.2.1">2.2.1.</a> <a href="#pEp" id="pEp">Pretty Easy Privacy (pEp)</a>
</h1>
<p id="rfc.section.2.2.1.p.1">To achieve privacy of exchanged messages in an opportunistic way <a href="#RFC7435" class="xref">[RFC7435]</a>, the following model (simplified) is proposed by pEp (pretty Easy Privacy) <a href="#I-D.birk-pep" class="xref">[I-D.birk-pep]</a>:</p>
<pre>
----- -----
| A | | B |
----- -----
| |
+------------------------+ +------------------------+
| auto-generate key pair | | auto-generate key pair |
| (if no key yet) | | (if no key yet) |
+------------------------+ +------------------------+
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Unencrypted* | | *Unencrypted* |
+-----------------------+ +-----------------------+
| |
| A sends message to B (Public Key |
| attached) / optionally signed, but |
| NOT ENCRYPTED |
+------------------------------------------&gt;|
| |
| +-----------------------+
| | Privacy Status for A: |
| | *Encrypted* |
| +-----------------------+
| |
| B sends message to A (Public Key |
| attached) / signed and ENCRYPTED |
|&lt;------------------------------------------+
| |
+-----------------------+ |
| Privacy Status for B: | |
| *Encrypted* | |
+-----------------------+ |
| |
| A and B sucessfully compare their |
| Trustwords over an alternative channel |
| (e.g., phone line) |
|&lt;-- -- -- -- -- -- -- -- -- -- -- -- -- --&gt;|
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Trusted* | | *Trusted* |
+-----------------------+ +-----------------------+
| |
</pre>
<p><br><br><br><br><br><br><br><br><br><br><br></p>
<p id="rfc.section.2.2.1.p.3">pEp is supposed to solve three problems :</p>
<p></p>
<ul>
<li>Key management</li>
<li>Trust management</li>
<li>Identity management</li>
</ul>
<p id="rfc.section.2.2.1.p.5">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.</p>
<p id="rfc.section.2.2.1.p.6">And pEp is supposed to provide technical data protection by implementing mix network capabilities.</p>
<p id="rfc.section.2.2.1.p.7">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</p>
<p id="rfc.section.2.2.1.p.8">[[ TODO: Decide whether enterprise requirements will be covered herein ]]</p>
<h1 id="rfc.section.2.2.2">
<a href="#rfc.section.2.2.2">2.2.2.</a> <a href="#autocrypt" id="autocrypt">Autocrypt</a>
</h1>
<p id="rfc.section.2.2.2.p.1">The Autocrypt approach is also a known project following the above mentioned principles, though - compared to pEp (cf. <a href="#pEp" class="xref">Section 2.2.1</a>) - the goals slightly differ, for example regarding support of legacy PGP <a href="#RFC4880" class="xref">[RFC4880]</a> implementations.</p>
<p id="rfc.section.2.2.2.p.2">More information on Autocypt can be found on: https://autocrypt.org/background.html</p>
<p id="rfc.section.2.2.2.p.3">[[ TODO: Input from autocrypt group ]]</p>
<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. 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>
<li>Message: send and receive message(s)</li>
<li>Multi-device support: synchronisation across multiple devices</li>
<li>Group messaging: communication of more than 2 users</li>
</ul>
<p id="rfc.section.3.p.3">[[ TODO: Add more text on Group Messaging requirements. ]]</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#threat-analyses" id="threat-analyses">Threat Analyses</a>
</h1>
<p id="rfc.section.4.p.1">This section describes a set of possible threats. Note that not all threats can be addressed, due to conflicting requirements.</p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#establish-evaluation-criteria-for" id="establish-evaluation-criteria-for">Establish Evaluation Criteria for:</a>
</h1>
<p></p>
<ul>
<li>Security and privacy requirements</li>
<li>Usability (little work on usability and trust establishment)</li>
<li>Adoption implications</li>
</ul>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#focus-areas-design-challenges" id="focus-areas-design-challenges">Focus Areas (Design Challenges):</a>
</h1>
<p></p>
<ul>
<li>Trust establishment: some human interaction</li>
<li>Conversation security: no human interaction</li>
<li>Transport privacy: no human interaction</li>
</ul>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#system-model" id="system-model">System Model</a>
</h1>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#entities" id="entities">Entities</a>
</h1>
<p></p>
<ul>
<li>Users: Sender and receiver(s) <br><br> There are the communicating parties such as the sender and receiver of messages.</li>
<li>Messaging operators and network nodes <br><br> Are the servers and network nodes who are responsible for message delivery and synchronization.</li>
<li>Third parties <br><br> It is any other entity who is interacting with the system.</li>
</ul>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#problem-areas" id="problem-areas">Problem Areas</a>
</h1>
<h1 id="rfc.section.6.1">
<a href="#rfc.section.6.1">6.1.</a> <a href="#security-threats-and-requirements" id="security-threats-and-requirements">Security Threats and Requirements</a>
</h1>
<h1 id="rfc.section.6.1.1">
<a href="#rfc.section.6.1.1">6.1.1.</a> <a href="#spoofing-and-entity-authentication" id="spoofing-and-entity-authentication">Spoofing and Entity Authentication</a>
</h1>
<p id="rfc.section.6.1.1.p.1">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.</p>
<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 <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>
<p id="rfc.section.6.1.3.p.1">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.</p>
<h1 id="rfc.section.6.1.4">
<a href="#rfc.section.6.1.4">6.1.4.</a> <a href="#repudiation-and-accountability-non-repudiation" id="repudiation-and-accountability-non-repudiation">Repudiation and Accountability (Non-Repudiation)</a>
</h1>
<p id="rfc.section.6.1.4.p.1">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.</p>
<h1 id="rfc.section.6.2">
<a href="#rfc.section.6.2">6.2.</a> <a href="#privacy-threats-and-requirements" id="privacy-threats-and-requirements">Privacy Threats and Requirements</a>
</h1>
<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; <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>
<p id="rfc.section.6.2.2.p.1">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.</p>
<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; <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>
<p id="rfc.section.6.3.p.1">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.</p>
<h1 id="rfc.section.6.4">
<a href="#rfc.section.6.4">6.4.</a> <a href="#non-repudiation-and-deniability" id="non-repudiation-and-deniability">Non-repudiation and deniability</a>
</h1>
<p id="rfc.section.6.4.p.1">In contrast to security, non-repudiation can be a threat to a user&#8217;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.</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#specific-security-and-privacy-requirements" id="specific-security-and-privacy-requirements">Specific Security and Privacy Requirements</a>
</h1>
<h1 id="rfc.section.7.1">
<a href="#rfc.section.7.1">7.1.</a> <a href="#messages-exchange" id="messages-exchange">Messages Exchange</a>
</h1>
<h1 id="rfc.section.7.1.1">
<a href="#rfc.section.7.1.1">7.1.1.</a> <a href="#send-message" id="send-message">Send Message</a>
</h1>
<p></p>
<ul>
<li>Send encrypted and signed message to another peer</li>
<li>Send unencrypted and unsigned message to another peer <br><br> Note: Subcases of sending messages are outlined in <a href="#subcases-for-sending-messages" class="xref">Section 8.2</a>.</li>
</ul>
<h1 id="rfc.section.7.1.2">
<a href="#rfc.section.7.1.2">7.1.2.</a> <a href="#receive-message" id="receive-message">Receive Message</a>
</h1>
<p></p>
<ul>
<li>Receive encrypted and signed message from another peer</li>
<li>Receive encrypted, but not signed message from another peer</li>
<li>Receive signed, but not encrypted message from another peer</li>
<li>Receive unencrypted and unsigned message from another peer <br><br> Note: Subcases of receiving messages are outlined in <a href="#subcases-for-receiving-messages" class="xref">Section 8.3</a>.</li>
</ul>
<h1 id="rfc.section.7.2">
<a href="#rfc.section.7.2">7.2.</a> <a href="#trust-management" id="trust-management">Trust Management</a>
</h1>
<p></p>
<ul>
<li>Trust rating of a peer is updated (locally) when: <ul>
<li>Public Key is received the first time</li>
<li>Trustwords have been compared successfully and confirmed by user (see above)</li>
<li>Trust of a peer is revoked (cf. <a href="#key-management" class="xref">Section 7.3</a>, Key Reset)</li>
</ul>
</li>
<li>Trust of a public key is synchronized among different devices of the same user <br><br> Note: Synchronization management (such as establish or revoke trust) among a user&#8217;s own devices is described in <a href="#synchronization-management" class="xref">Section 7.4</a>
</li>
</ul>
<h1 id="rfc.section.7.3">
<a href="#rfc.section.7.3">7.3.</a> <a href="#key-management" id="key-management">Key Management</a>
</h1>
<p></p>
<ul>
<li>New Key pair is generated automatically (if none found) at startup</li>
<li>Public Key is sent to peer by attaching it to messages</li>
<li>Public Key received by a peer is stored locally</li>
<li>Key pair is declared invalid and other peers are informed (Key Reset)</li>
<li>Public Key is marked invalid after receiving a key reset message</li>
<li>Public Keys are are of peers are synchronized among different devices of the same user</li>
<li>Private Key is synchronized among different devices of the same user <br><br> Note: Synchronization management (such as establish or revoke trust) among a user&#8217;s own devices is described in <a href="#synchronization-management" class="xref">Section 7.4</a>
</li>
</ul>
<h1 id="rfc.section.7.4">
<a href="#rfc.section.7.4">7.4.</a> <a href="#synchronization-management" id="synchronization-management">Synchronization Management</a>
</h1>
<p id="rfc.section.7.4.p.1">A device group is a group of devices of the same user that share the same key pairs in order to synchronize data among them. In a device group devices of the same user mutually grant authentication.</p>
<p></p>
<ul><li>Form a device group of two (yet ungrouped) devices of the same user</li></ul>
<p></p>
<ul>
<li>Join another device of the same user to existing device group</li>
<li>Leave device group</li>
<li>Remove other device from device group</li>
</ul>
<h1 id="rfc.section.7.5">
<a href="#rfc.section.7.5">7.5.</a> <a href="#identity-management" id="identity-management">Identity Management</a>
</h1>
<p></p>
<ul><li>All involved parties share the same identity system</li></ul>
<h1 id="rfc.section.7.6">
<a href="#rfc.section.7.6">7.6.</a> <a href="#user-interface" id="user-interface">User Interface</a>
</h1>
<p></p>
<ul>
<li>Need for user interaction is kept to the minimum necessary</li>
<li>The privacy status of a peer is presented to the user by a color rating</li>
<li>The privacy status of a message is presented to the user by a color rating</li>
<li>The color rating is defined by a traffic-light semantics</li>
</ul>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#subcases" id="subcases">Subcases</a>
</h1>
<h1 id="rfc.section.8.1">
<a href="#rfc.section.8.1">8.1.</a> <a href="#interaction-states" id="interaction-states">Interaction States</a>
</h1>
<p id="rfc.section.8.1.p.1">The basic model consists of three different interaction states, i.e.:</p>
<p></p>
<ol>
<li>Both peers have got no public key of each other, no trust possible</li>
<li>Only one peer has got the public key of the other peer, but no trust</li>
<li>Only one peer has got the public key of the other peer and trusts that public key</li>
<li>Both peers have got the public key of each other, but no trust</li>
<li>Both peers have got the public key of each other, but only one peer trusts the other peer&#8217;s public key</li>
<li>Both peers have got the public key of each other and both peers trust each others public key</li>
</ol>
<p id="rfc.section.8.1.p.3">The following table shows the different interaction states possible:</p>
<table cellpadding="3" cellspacing="0" class="tt full center">
<thead><tr>
<th class="left">state</th>
<th class="center">Peer&#8217;s Public Key available</th>
<th class="center">My Public Key available to Peer</th>
<th class="center">Peer Trusted</th>
<th class="center">Peer trusts me</th>
</tr></thead>
<tbody>
<tr>
<td class="left">1.</td>
<td class="center">no</td>
<td class="center">no</td>
<td class="center">N/A</td>
<td class="center">N/A</td>
</tr>
<tr>
<td class="left">2a.</td>
<td class="center">no</td>
<td class="center">yes</td>
<td class="center">N/A</td>
<td class="center">no</td>
</tr>
<tr>
<td class="left">2b.</td>
<td class="center">yes</td>
<td class="center">no</td>
<td class="center">no</td>
<td class="center">N/A</td>
</tr>
<tr>
<td class="left">3a.</td>
<td class="center">no</td>
<td class="center">yes</td>
<td class="center">N/A</td>
<td class="center">yes</td>
</tr>
<tr>
<td class="left">3b.</td>
<td class="center">yes</td>
<td class="center">no</td>
<td class="center">yes</td>
<td class="center">N/A</td>
</tr>
<tr>
<td class="left">4.</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">no</td>
<td class="center">no</td>
</tr>
<tr>
<td class="left">5a.</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">no</td>
<td class="center">yes</td>
</tr>
<tr>
<td class="left">5b.</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">no</td>
</tr>
<tr>
<td class="left">6.</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">yes</td>
<td class="center">yes</td>
</tr>
</tbody>
</table>
<p id="rfc.section.8.1.p.4">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.</p>
<p id="rfc.section.8.1.p.5">Note: As one peer may have several keys or if group conversations are involved, things will get more complex. For the time being, we focus on bilateral interactions, whereas group interactions are split up into several bilateral interactions.</p>
<h1 id="rfc.section.8.2">
<a href="#rfc.section.8.2">8.2.</a> <a href="#subcases-for-sending-messages" id="subcases-for-sending-messages">Subcases for Sending Messages</a>
</h1>
<p></p>
<ul>
<li>If peer&#8217;s Public Key not available (Interaction States 1, 2a, and 3a) <ul><li>Send message Unencrypted (and not Signed)</li></ul>
</li>
<li>If peer&#8217;s Public Key available (Interaction States 2b, 3b, 4, 5a, 5b, 6) <ul><li>Send message Encrypted and Signed</li></ul>
</li>
</ul>
<h1 id="rfc.section.8.3">
<a href="#rfc.section.8.3">8.3.</a> <a href="#subcases-for-receiving-messages" id="subcases-for-receiving-messages">Subcases for Receiving Messages</a>
</h1>
<p></p>
<ul>
<li>If peer&#8217;s Public Key not available (Interaction States 1, 2a, and 3a) <ul>
<li>If message is signed <ul><li>ignore signature</li></ul>
</li>
<li>If message is encrypted <ul><li>decrypt with caution</li></ul>
</li>
<li>If message not encrypted <ul><li>No further processing regarding encryption</li></ul>
</li>
</ul>
</li>
<li>If peer&#8217;s Public Key available or can be retrieved from received message (Interaction States 2b, 3b, 4, 5a, 5b, 6) <ul>
<li>If message is signed <ul>
<li>verify signature</li>
<li>If message is encrypted <ul><li>Decrypt</li></ul>
</li>
<li>If message not encrypted <ul><li>No further processing regarding encryption</li></ul>
</li>
</ul>
</li>
<li>If message not signed <ul>
<li>If message is encrypted <ul><li>exception</li></ul>
</li>
<li>If message not encrypted <ul><li>No further processing regarding encryption</li></ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.9.p.1">Relevant security considerations are outlined in <a href="#security-threats-and-requirements" class="xref">Section 6.1</a>.</p>
<h1 id="rfc.section.10">
<a href="#rfc.section.10">10.</a> <a href="#privacy-considerations" id="privacy-considerations">Privacy Considerations</a>
</h1>
<p id="rfc.section.10.p.1">Relevant privacy considerations are outlined in <a href="#privacy-threats-and-requirements" class="xref">Section 6.2</a>.</p>
<h1 id="rfc.section.11">
<a href="#rfc.section.11">11.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.11.p.1">This document requests no action from IANA.</p>
<p id="rfc.section.11.p.2">[[ RFC Editor: This section may be removed before publication. ]]</p>
<h1 id="rfc.section.12">
<a href="#rfc.section.12">12.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.12.p.1">The authors would like to thank the following people who have provided feedback or significant contributions to the development of this document: Volker Birk [[ TODO: Forename Surname, Forename2 Surname2, &#8230;]]</p>
<p id="rfc.section.12.p.2">lorem ipsum</p>
<h1 id="rfc.references">
<a href="#rfc.references">13.</a> References</h1>
<h1 id="rfc.references.1">
<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>
</tr>
<tr>
<td class="reference"><b id="RFC4949">[RFC4949]</b></td>
<td class="top">
<a>Shirey, R.</a>, "<a href="https://tools.ietf.org/html/rfc4949">Internet Security Glossary, Version 2</a>", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7435">[RFC7435]</b></td>
<td class="top">
<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="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>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">13.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.birk-pep">[I-D.birk-pep]</b></td>
<td class="top">
<a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-birk-pep-03">pretty Easy privacy (pEp): Privacy by Default</a>", Internet-Draft draft-birk-pep-03, March 2019.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.birk-pep-trustwords">[I-D.birk-pep-trustwords]</b></td>
<td class="top">
<a>Birk, V.</a>, <a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-birk-pep-trustwords-03">IANA Registration of Trustword Lists: Guide, Template and IANA Considerations</a>", Internet-Draft draft-birk-pep-trustwords-03, March 2019.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4880">[RFC4880]</b></td>
<td class="top">
<a>Callas, J.</a>, <a>Donnerhacke, L.</a>, <a>Finney, H.</a>, <a>Shaw, D.</a> and <a>R. Thayer</a>, "<a href="https://tools.ietf.org/html/rfc4880">OpenPGP Message Format</a>", RFC 4880, DOI 10.17487/RFC4880, November 2007.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8280">[RFC8280]</b></td>
<td class="top">
<a>ten Oever, N.</a> and <a>C. Cath</a>, "<a href="https://tools.ietf.org/html/rfc8280">Research into Human Rights Protocol Considerations</a>", RFC 8280, DOI 10.17487/RFC8280, October 2017.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
</h1>
<p id="rfc.section.A.p.1">[[ RFC Editor: This section is to be removed before publication ]]</p>
<p></p>
<ul><li>draft-symeonidis-medup-requirements-00: <ul><li>Initial version</li></ul>
</li></ul>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#open-issues" id="open-issues">Open Issues</a>
</h1>
<p id="rfc.section.B.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication ]]</p>
<p></p>
<ul>
<li>Add references to used materials (in particular threat analyses part)</li>
<li>Get content from Autocrypt (<a href="#autocrypt" class="xref">Section 2.2.2</a>)</li>
<li>Add more text on Group Messaging requirements</li>
<li>Decide on whether or not &#8220;enterprise requirement&#8221; will go to this document</li>
</ul>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Iraklis Symeonidis</span>
<span class="n hidden">
<span class="family-name">Symeonidis</span>
</span>
</span>
<span class="org vcardline">University of Luxembourg</span>
<span class="adr">
<span class="vcardline">29, avenue JF Kennedy</span>
<span class="vcardline">
<span class="locality">L-1855 Luxembourg</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">Luxembourg</span>
</span>
<span class="vcardline">EMail: <a href="mailto:iraklis.symeonidis@uni.lu">iraklis.symeonidis@uni.lu</a></span>
<span class="vcardline">URI: <a href="https://wwwen.uni.lu/snt/people/iraklis_symeonidis">https://wwwen.uni.lu/snt/people/iraklis_symeonidis</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Bernie Hoeneisen</span>
<span class="n hidden">
<span class="family-name">Hoeneisen</span>
</span>
</span>
<span class="org vcardline">Ucom Standards Track Solutions GmbH</span>
<span class="adr">
<span class="vcardline">
<span class="locality">CH-8046 Zuerich</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">Switzerland</span>
</span>
<span class="vcardline">Phone: +41 44 500 52 44</span>
<span class="vcardline">EMail: <a href="mailto:bernie@ietf.hoeneisen.ch%20(bernhard.hoeneisen%20AT%20ucom.ch)">bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)</a></span>
<span class="vcardline">URI: <a href="https://ucom.ch/">https://ucom.ch/</a></span>
</address>
</div>
</body>
</html>