Browse Source

version rollover

master
Bernie Hoeneisen 3 years ago
parent
commit
7366acafec
5 changed files with 3215 additions and 3 deletions
  1. +2
    -2
      lamps-header-protection/Makefile
  2. +984
    -0
      lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-03.html
  3. +952
    -0
      lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-03.txt
  4. +1276
    -0
      lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-03.xml
  5. +1
    -1
      lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd

+ 2
- 2
lamps-header-protection/Makefile View File

@ -1,7 +1,7 @@
#!/usr/bin/make -f
NAME := draft-luck-lamps-pep-header-protection
REV := 03
REV := 04
DRAFT := $(NAME)-$(REV)
OUTPUTS = $(DRAFT).xml $(DRAFT).txt $(DRAFT).html
@ -12,7 +12,6 @@ all: $(OUTPUTS)
$(DRAFT).xml: $(NAME).mkd \
../shared/author_tags/claudio_luck.mkd \
../shared/author_tags/bernie_hoeneisen.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
../shared/text-blocks/terms-intro.mkd \
@ -25,6 +24,7 @@ $(DRAFT).xml: $(NAME).mkd \
# ../shared/ascii-arts/basic-msg-flow.mkd \
# ../shared/ascii-arts/pep_id_system.mkd \
# to match backslash at the end of the previous line
# ../shared/author_tags/bernie_hoeneisen.mkd \
kramdown-rfc2629 $(NAME).mkd > $(DRAFT).xml
$(DRAFT).txt: $(DRAFT).xml


+ 984
- 0
lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-03.html View File

@ -0,0 +1,984 @@
<!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>pretty Easy privacy (pEp): Progressive Header Disclosure</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 Message Format for Progressive Header Disclosure">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Compatibility">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Inner Message">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Content-Type Parameter &#8220;forwarded&#8221;">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Outer Message">
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 Transport Message">
<link href="#rfc.section.2.6" rel="Chapter" title="2.6 S/MIME Compatibility">
<link href="#rfc.section.3" rel="Chapter" title="3 Candidate Header Fields for Header Protection">
<link href="#rfc.section.4" rel="Chapter" title="4 Stub Outside Headers">
<link href="#rfc.section.5" rel="Chapter" title="5 Processing Incoming Email under Progressive Header Disclosure">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Processing of Signed-only Email">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Incoming Filter Processing">
<link href="#rfc.section.5.2.1" rel="Chapter" title="5.2.1 Staged Filtering of Inbound Messages">
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Outgoing Filter Processing">
<link href="#rfc.section.6" rel="Chapter" title="6 Security Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 Privacy Considerations">
<link href="#rfc.section.8" rel="Chapter" title="8 IANA Considerations">
<link href="#rfc.section.9" rel="Chapter" title="9 Implementation Status">
<link href="#rfc.section.9.1" rel="Chapter" title="9.1 Introduction">
<link href="#rfc.section.9.2" rel="Chapter" title="9.2 Current software implementing pEp">
<link href="#rfc.section.10" rel="Chapter" title="10 Acknowledgements">
<link href="#rfc.references" rel="Chapter" title="11 References">
<link href="#rfc.references.1" rel="Chapter" title="11.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="11.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A About pEp Design Principles">
<link href="#rfc.appendix.B" rel="Chapter" title="B Document Changelog">
<link href="#rfc.appendix.C" rel="Chapter" title="C 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="Luck, C." />
<meta name="dct.identifier" content="urn:ietf:id:draft-luck-lamps-pep-header-protection-03" />
<meta name="dct.issued" scheme="ISO8601" content="2019-07-05" />
<meta name="dct.abstract" content="Issues with email header protection in S&#8203;/&#8203;MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed." />
<meta name="description" content="Issues with email header protection in S&#8203;/&#8203;MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">C. Luck</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">pEp Foundation</td>
</tr>
<tr>
<td class="left">Intended status: Informational</td>
<td class="right">July 05, 2019</td>
</tr>
<tr>
<td class="left">Expires: January 6, 2020</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">pretty Easy privacy (pEp): Progressive Header Disclosure<br />
<span class="filename">draft-luck-lamps-pep-header-protection-03</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>Issues with email header protection in S&#8203;/&#8203;MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed.</p>
<p>The pretty Easy privacy (pEp) implementations currently use a mechanism quite similar to the currently standardized message wrapping for S&#8203;/&#8203;MIME. The main difference is that pEp is using PGP/MIME instead, and adds space for carrying public keys next to the protected message.</p>
<p>In LAMPS, it has been expressed that whatever mechanism will be chosen, it should not be limited to S&#8203;/&#8203;MIME, but also applicable to PGP/MIME.</p>
<p>This document aims to contribute to this discussion and share the pEp implementation experience with email header protection.</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 January 6, 2020.</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">Message Format for Progressive Header Disclosure</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Compatibility</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Inner Message</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">Content-Type Parameter &#8220;forwarded&#8221;</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Outer Message</a>
</li>
<li>2.5. <a href="#rfc.section.2.5">Transport Message</a>
</li>
<li>2.6. <a href="#rfc.section.2.6">S/MIME Compatibility</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Candidate Header Fields for Header Protection</a>
</li>
<li>4. <a href="#rfc.section.4">Stub Outside Headers</a>
</li>
<li>5. <a href="#rfc.section.5">Processing Incoming Email under Progressive Header Disclosure</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Processing of Signed-only Email</a>
</li>
<li>5.2. <a href="#rfc.section.5.2">Incoming Filter Processing</a>
</li>
<ul><li>5.2.1. <a href="#rfc.section.5.2.1">Staged Filtering of Inbound Messages</a>
</li>
</ul><li>5.3. <a href="#rfc.section.5.3">Outgoing Filter Processing</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Security Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">Privacy Considerations</a>
</li>
<li>8. <a href="#rfc.section.8">IANA Considerations</a>
</li>
<li>9. <a href="#rfc.section.9">Implementation Status</a>
</li>
<ul><li>9.1. <a href="#rfc.section.9.1">Introduction</a>
</li>
<li>9.2. <a href="#rfc.section.9.2">Current software implementing pEp</a>
</li>
</ul><li>10. <a href="#rfc.section.10">Acknowledgements</a>
</li>
<li>11. <a href="#rfc.references">References</a>
</li>
<ul><li>11.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>11.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">About pEp Design Principles</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Document Changelog</a>
</li>
<li>Appendix C. <a href="#rfc.appendix.C">Open Issues</a>
</li>
<li><a href="#rfc.authors">Author's Address</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">A range of protocols for the protection of electronic mail (email) exist, which allow to assess the authenticity and integrity of the email headers section, or selected header fields, but limited to a domain-level perspective. Specifically these are DomainKeys Identified Mail (DKIM) <a href="#RFC6376" class="xref">[RFC6376]</a> and Sender Policy Framework (SPF) <a href="#RFC7208" class="xref">[RFC7208]</a> and Domain-based Message Authentication, Reporting, and Conformance (DMARC) <a href="#RFC7489" class="xref">[RFC7489]</a>. These protocols, while essential to responding to a range of attacks on email, do not offer full End-to-End protection to the headers section and are not capable of providing privacy regarding the information represented therein.</p>
<p id="rfc.section.1.p.2">The need for means of Data Minimization, which includes data spareness and hiding of all information technically hideable, has grown in importance over the past years.</p>
<p id="rfc.section.1.p.3">A standard for End-to-End protection of the email headers section exists for S&#8203;/&#8203;MIME since version 3.1. (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>):</p>
<p></p>
<ul class="empty"><li>In order to protect outer, non-content-related message header fields (for instance, the &#8220;Subject&#8221;, &#8220;To&#8221;, &#8220;From&#8221;, and &#8220;Cc&#8221; fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S&#8203;/&#8203;MIME security services to these header fields.</li></ul>
<p id="rfc.section.1.p.5">No mechanism for header protection has been standardized for <a href="#PGPMIME" class="xref">[PGPMIME]</a> yet.</p>
<p id="rfc.section.1.p.6">End-to-End protection for the email headers section is currently not widely implemented &#8211; neither for messages protected by means of S&#8203;/&#8203;MIME nor PGP/MIME. At least two variants of header protection are known to be implemented. A recently submitted Internet-Draft <a href="#I-D.melnikov-lamps-header-protection" class="xref">[I-D.melnikov-lamps-header-protection]</a> discusses the two variants and the challenges with header protection for S&#8203;/&#8203;MIME. The two variants are referred to as:</p>
<p></p>
<ul>
<li>Option 1: Memory Hole</li>
<li>Option 2: Wrapping with message/rfc822 or message/global</li>
</ul>
<p id="rfc.section.1.p.8">pEp (pretty Easy privacy) <a href="#I-D.birk-pep" class="xref">[I-D.birk-pep]</a> for email <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a> already implements an option quite similar to Option 2, adapting the S&#8203;/&#8203;MIME standards to PGP/MIME (cf. <a href="#message-format-for-progressive-header-disclosure" class="xref">Section 2</a>, ff.). Existing implementations of pEp have also added inbound support for &#8220;Memory Hole&#8221; referred to above as Option 1, thus being able to study the differences and the implementator&#8217;s challenges.</p>
<p id="rfc.section.1.p.9">pEp now also supports the &#8220;forwarded=no&#8221; attribute proposed in <a href="#I-D.melnikov-lamps-header-protection" class="xref">[I-D.melnikov-lamps-header-protection]</a>, and further described in <a href="#forwarded-no" class="xref">Section 2.3</a>.</p>
<p id="rfc.section.1.p.10">Interoperability and implementation symmetry between PGP/MIME and S&#8203;/&#8203;MIME is planned by pEp, but still in an early stage of development.</p>
<p id="rfc.section.1.p.11">This document describes Progressive Header Disclosure as implemented in the &#8220;pEp message format version 2&#8221;. This format inherently offers header protection as a side effect, but is only intended for use only with signed-and-encrypted messages. The feature of protecting headers may be used independently by mail user agents otherwise not wanting to conform to pEp standards (<a href="#message-format-for-progressive-header-disclosure" class="xref">Section 2</a>, ff.).</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>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="#message-format-for-progressive-header-disclosure" id="message-format-for-progressive-header-disclosure">Message Format for Progressive Header Disclosure</a>
</h1>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#compatibility" id="compatibility">Compatibility</a>
</h1>
<p id="rfc.section.2.1.p.1">The pEp message format version 2 is designed such that a receiving Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-compliant, still has built-in capability to properly verify the integrity of the mail, decode it and display all information of the original mail to the user. The recovered protected message is selfsufficiently described, including all protected header fields.</p>
<p id="rfc.section.2.1.p.2">The pEp message format version 2 (as used by all the various pEp implementations, cf. <a href="#implementation-status" class="xref">Section 9</a>) is similar to what is standardized for S&#8203;/&#8203;MIME in <a href="#RFC8551" class="xref">[RFC8551]</a>:</p>
<p></p>
<ul class="empty">
<li>In order to protect outer, non-content-related message header fields (for instance, the &#8220;Subject&#8221;, &#8220;To&#8221;, &#8220;From&#8221;, and &#8220;Cc&#8221; fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S&#8203;/&#8203;MIME security services to these header fields. It is up to the receiving client to decide how to present this &#8220;inner&#8221; header along with the unprotected &#8220;outer&#8221; header.</li>
<li>When an S&#8203;/&#8203;MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, [&#8230;].</li>
</ul>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#inner-message" id="inner-message">Inner Message</a>
</h1>
<p><strong>Note</strong>: this section is for your information only. It does not add requirements for the header protection feature to work.</p>
<p id="rfc.section.2.2.p.2">The pEp message format requires the innermost protected message to follow a fixed MIME structure and to consist of exactly one human-readable message which is represented in plain or HTML format. Both plain and html entities MUST represent the same message to the user. Any attachment to the message must be laid out in a flat list. No additional multipart entities are allowed in the pEp message.</p>
<p id="rfc.section.2.2.p.3">These restrictions permit to build mail user agents which are immune to the EFAIL attacks.</p>
<p id="rfc.section.2.2.p.4">This message is herein further referred to as the &#8220;pEp inner message&#8221;.</p>
<p id="rfc.section.2.2.p.5">A mail user agent wanting to follow this standard, SHOULD transform any &#8220;original message&#8221; into a &#8220;pEp inner message&#8221; for safe representation on the receiving side.</p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#forwarded-no" id="forwarded-no">Content-Type Parameter &#8220;forwarded&#8221;</a>
</h1>
<p id="rfc.section.2.3.p.1">One caveat of the design is that the user interaction with message/rfc822 entities varies considerably across different mail user agents. No standard is currently available which enables MUAs to reliably determine whenever a nested message/rfc822 entity is meant to blend the containing message, or if it was effectively intended to be forwarded as a file document. pEp currently implements the proposal described by <a href="#I-D.melnikov-lamps-header-protection" class="xref">[I-D.melnikov-lamps-header-protection]</a>, 3.2, which defines a new Content-Type header field parameter with name &#8220;forwarded&#8221;, for the MUA to distinguish between a forwarded message and a nested message for the purpose of header protection, i.e., using &#8220;forwarded=no&#8221;.</p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#outer-message" id="outer-message">Outer Message</a>
</h1>
<p id="rfc.section.2.4.p.1">With pEp message format version 2, the pEp standardized message is equally wrapped in a message/rfc822 entity, but this time being in turn wrapped in a multipart/mixed entity. The purpose of the additional nesting is to allow for public keys of the sender to be stored alongside the original message while being protected by the same mechanism.</p>
<p id="rfc.section.2.4.p.2">For the case of PGP/MIME, the currently only implemented MIME encryption protocol implemented in pEp, the top-level entity called the &#8220;outer message&#8221; MUST contain:</p>
<p></p>
<ul>
<li>exactly one entity of type message/rfc822, and</li>
<li>one or more entity of type application/pgp-keys</li>
</ul>
<p id="rfc.section.2.4.p.4">Notes on the current pEp client implementations:</p>
<p></p>
<ul>
<li>the current pEp implementation also adds a text/plain entity containing &#8220;pEp-Wrapped-Message-Info: OUTER&#8221; as first element in the MIME tree. This element is not strictly necessary, but is in place for better backwards compatibility when manually navigating the nested message structure. This is part of the study of various solutions to maximize backwards compatibility, and has been omitted from the following examples.</li>
<li>the current pEp implementation prepends &#8220;pEp-Wrapped-Message-Info: INNER&lt;CR&gt;&lt;LF&gt;&#8221; to the original message body. This is an implementation detail which should be ignored, and has been omitted in the following examples.</li>
<li>the current pEp implementation may render a text/plain directly in place of the multipart/alternate, when no HTML representation was generated by the sending MUA. This is not strict according to pEp&#8217;s own specification, and is currently being investigated.</li>
</ul>
<p id="rfc.section.2.4.p.6">This is an example of the top-level MIME entity, before being encrypted and signed:</p>
<pre>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="6b8b4567327b23c6643c986966334873"
--6b8b4567327b23c6643c986966334873
Content-Type: message/rfc822; forwarded="no"
From: John Doe &lt;jdoe@machine.example&gt;
To: Mary Smith &lt;mary@example.net&gt;
Subject: Example
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: &lt;05d0526e-41c4-11e9-8828@pretty.Easy.privacy&gt;
X-Pep-Version: 2.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
--29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="msg.txt"
p=E2=89=A1p for Privacy by Default.
-- =20
Sent from my p=E2=89=A1p for Android.
--29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
p=E2=89=A1p for Privacy by Default.&lt;br&gt;
-- &lt;br&gt;
Sent from my p=E2=89=A1p for Android.&lt;br&gt;
--29fe9d2b2d7f6a703c1bffc47c162a8c--
--6b8b4567327b23c6643c986966334873
Content-Type: application/pgp-keys
Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----
--6b8b4567327b23c6643c986966334873--
</pre>
<h1 id="rfc.section.2.5">
<a href="#rfc.section.2.5">2.5.</a> <a href="#transport-message" id="transport-message">Transport Message</a>
</h1>
<p id="rfc.section.2.5.p.1">In pEp message format 2 the &#8220;outer message&#8221; consists of a full RFC822 message with body and a minimal set of header fields, just those necessary to conform to MIME multipart standards.</p>
<p id="rfc.section.2.5.p.2">The &#8220;outer message&#8221; should be encrypted and carry a signature according to the MIME encryption standards. The resulting message is the transport message which a root entity of type multipart/encrypted.</p>
<p id="rfc.section.2.5.p.3">A minimal set of header fields should be set on the &#8220;transport message&#8221;, as to permit delivery, without disclosing private information.</p>
<p id="rfc.section.2.5.p.4">The structure of the transport message may be altered in-transit, e.g. through mailing list agents, or inspection gateways.</p>
<p id="rfc.section.2.5.p.5">Signing and encrypting a message with MIME Security with <a href="#PGPMIME" class="xref">[PGPMIME]</a>, yields a message with the following complete MIME structure, seen across the encryption layer:</p>
<pre>
= multipart/encrypted; protocol="application/pgp-encrypted";
+ application/pgp-encrypted [ Version: 1 ]
+ application/octet-stream; name="msg.asc"
{
Content-Disposition: inline; filename="msg.asc";
}
|
[ opaque encrypted structure ]
|
{ minimal headers }
+ multipart/mixed
+ message/rfc822; forwarded="no";
|
{ protected message headers }
+ multipart/mixed
+ multipart/alternate
+ text/plain
+ text/html
+ application/octet-stream [ attachmet_1 ]
+ application/octet-stream [ attachmet_2 ]
+ application/pgp-keys
</pre>
<p id="rfc.section.2.5.p.6">The header fields of the sub-part of type application/octet-stream SHOULD be modified to ensure that:</p>
<p></p>
<ul>
<li>the Content-Type header field&#8217;s <ul>
<li>&#8220;name&#8221; parameter is set to the value &#8220;msg.asc&#8221;, and</li>
<li>parameter &#8220;forwarded&#8221; is set to &#8220;no&#8221;, and</li>
</ul>
</li>
<li>the Content-Disposition header field value is set to &#8220;inline&#8221; <ul><li>and the &#8220;filename&#8221; parameter is set to &#8220;msg.asc&#8221;.</li></ul>
</li>
</ul>
<h1 id="rfc.section.2.6">
<a href="#rfc.section.2.6">2.6.</a> <a href="#smime-compatibility" id="smime-compatibility">S/MIME Compatibility</a>
</h1>
<p id="rfc.section.2.6.p.1">Interoperability and implementation symmetry between PGP/MIME and S&#8203;/&#8203;MIME is on the roadmap of pEp.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#candidate-header-fields-for-header-protection" id="candidate-header-fields-for-header-protection">Candidate Header Fields for Header Protection</a>
</h1>
<p id="rfc.section.3.p.1">By default, all headers of the original message SHOULD be wrapped with the original message, with one exception:</p>
<p></p>
<ul><li>the header field &#8220;Bcc&#8221; MUST NOT be added to the protected headers.</li></ul>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#stub-outside-headers" id="stub-outside-headers">Stub Outside Headers</a>
</h1>
<p id="rfc.section.4.p.1">The outer message requires a minimal set of headers to be in place for being eligible for transport. This includes the &#8220;From&#8221;, &#8220;To&#8221;, &#8220;Cc&#8221;, &#8220;Bcc&#8221;, &#8220;Subject&#8221; and &#8220;Message-ID&#8221; header fields. The protocol hereby defined also depends on the &#8220;MIME-Version&#8221;, &#8220;Content-Type&#8221;, &#8220;Content-Disposition&#8221; and eventually the &#8220;Content-Transport-Encoding&#8221; header field to be present.</p>
<p id="rfc.section.4.p.2">Submission and forwarding based on SMTP carries &#8220;from&#8221; and &#8220;receivers&#8221; information out-of-band, so that the &#8220;From&#8221; and &#8220;To&#8221; header fields are not strictly necessary. Nevertheless, &#8220;From&#8221;, &#8220;Date&#8221;, and at least one destination header field is mandatory as per <a href="#RFC5322" class="xref">[RFC5322]</a>. They SHOULD be conserved for reliability.</p>
<p id="rfc.section.4.p.3">The following header fields should contain a verbatim copy of the header fields of the inner message:</p>
<p></p>
<ul>
<li>Date</li>
<li>From</li>
<li>To</li>
<li>Cc (*)</li>
<li>Bcc (*)</li>
</ul>
<p id="rfc.section.4.p.5">The entries with an asterisk mark (*) should only be set if also present in the original message.</p>
<p id="rfc.section.4.p.6">Clients which follow pEp standards MUST set the header field value for &#8220;Subject&#8221; to &#8220;=?utf-8?Q?p=E2=89=A1p?=&#8221; or &#8220;pEp&#8221;. Clients which do not adhere to all pEp standards should set the header field value of &#8220;Subject&#8221; to a descriptive stub value. An example used in practice is</p>
<p></p>
<ul><li>Subject: Encrypted message</li></ul>
<p id="rfc.section.4.p.8">The following header fields MUST be initialized with proper values according to the MIME standards:</p>
<p></p>
<ul>
<li>Content-Type</li>
<li>Content-Disposition</li>
<li>Content-Transport-Encoding (if necessary)</li>
</ul>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#processing-incoming-email-under-progressive-header-disclosure" id="processing-incoming-email-under-progressive-header-disclosure">Processing Incoming Email under Progressive Header Disclosure</a>
</h1>
<p id="rfc.section.5.p.1">[[ TODO ]]</p>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#processing-of-signed-only-email" id="processing-of-signed-only-email">Processing of Signed-only Email</a>
</h1>
<p id="rfc.section.5.1.p.1">pEp either engages in a signed-and-encrypted communication or in an unsigned plaintext communication. Inbound signatures attached to plaintext messages are duly verified but cannot enhance the perceived quality of the message in the user interface (while an invalid signature degrades the perception) <a href="#I-D.birk-pep" class="xref">[I-D.birk-pep]</a>.</p>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#incoming-filter-processing" id="incoming-filter-processing">Incoming Filter Processing</a>
</h1>
<p id="rfc.section.5.2.p.1">The Mail User Agent may implement outgoing filtering of mails, which may veto, alter, redirect or replicate the messages. The functionality may be implemented on the mailbox server and be configurable through a well-known protocol, e.g., by means of The Sieve Mail-Filtering Language <a href="#RFC5490" class="xref">[RFC5490]</a>, or be implemented client-side, or in a combination of both.</p>
<p id="rfc.section.5.2.p.2">A mailbox server, which is required to process the full range of possible filters, is requiring plaintext access to the header fields.</p>
<p id="rfc.section.5.2.p.3">In an End-to-End-encryption context, which pEp enforces by default, upon first reception of the message the mailbox server is limited to see the transport- relevant headers of the outer wrapper message. A pEp client configured to trust the server (&#8220;trusted server&#8221; setting <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>) will later download the encrypted message, decrypt it and replace the copy on the server by the decrypted copy.</p>
<h1 id="rfc.section.5.2.1">
<a href="#rfc.section.5.2.1">5.2.1.</a> <a href="#staged-filtering-of-inbound-messages" id="staged-filtering-of-inbound-messages">Staged Filtering of Inbound Messages</a>
</h1>
<p id="rfc.section.5.2.1.p.1">Inbound messages are expected to be delivered to the inbox while still being encrypted. At this point in time, server-side filtering can only evaluate the unprotected header fields in the wrapper message.</p>
<p id="rfc.section.5.2.1.p.2">In an End-to-End-encryption context, which pEp enforces by default, the mailbox server is limited to see the transport-relevant headers of the outer wrapper message only upon first delivery. A pEp client configured to trust the server (&#8220;trusted server&#8221; setting <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>) will eventually download the encrypted message, decrypt it locally and replace the copy on the server by the decrypted copy. Server-side message filters SHOULD be able to detect such post-processed messages, and apply the pending filters. The client SHOULD easily reflect the post-filtered messages in the user interface.</p>
<h1 id="rfc.section.5.3">
<a href="#rfc.section.5.3">5.3.</a> <a href="#outgoing-filter-processing" id="outgoing-filter-processing">Outgoing Filter Processing</a>
</h1>
<p id="rfc.section.5.3.p.1">The Mail User Agent may implement outgoing filtering of emails, which may veto, alter or replicate the email. They may also hint the MUA to store a copy in an alternate &#8220;Sent&#8221; folder.</p>
<p id="rfc.section.5.3.p.2">Filters which veto the sending or do alter the mail or replicate it (e.g., mass-mail generators) SHOULD be completed prior to applying protection, and thus also prior to applying header protection. Redirection to alternate &#8220;Sent&#8221; folders MUST NOT be decided prior to applying protection, but MUAs MAY abide from this restriction if they implement the &#8220;trusted server&#8221; option and the option is selected for the specific mailbox server; in this case, MUAs MUST NOT allow to redirect a message to an untrusted server by these rules, to prevent information leakage to the untrusted server.</p>
<p id="rfc.section.5.3.p.3">[[ TODO: Mention implicit filter for minimal color-rating for message replication. ]]</p>
<p id="rfc.section.5.3.p.4">[[ TODO: How to produce key-export-mails manually this way? That is, what about non-pEp-mode? ]]</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.6.p.1">[[ TODO ]]</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#privacy-considerations" id="privacy-considerations">Privacy Considerations</a>
</h1>
<p id="rfc.section.7.p.1">[[ TODO ]]</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.8.p.1">This document has no actions for IANA.</p>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#implementation-status" id="implementation-status">Implementation Status</a>
</h1>
<h1 id="rfc.section.9.1">
<a href="#rfc.section.9.1">9.1.</a> <a href="#introduction-1" id="introduction-1">Introduction</a>
</h1>
<p id="rfc.section.9.1.p.1">This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <a href="#RFC7942" class="xref">[RFC7942]</a>. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</p>
<p id="rfc.section.9.1.p.2">According to <a href="#RFC7942" class="xref">[RFC7942]</a>, &#8220;[&#8230;] this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit.&#8221;</p>
<h1 id="rfc.section.9.2">
<a href="#rfc.section.9.2">9.2.</a> <a href="#current-software-implementing-pep" id="current-software-implementing-pep">Current software implementing pEp</a>
</h1>
<p id="rfc.section.9.2.p.1">The following software implementing the pEp protocols (to varying degrees) already exists:</p>
<p></p>
<ul>
<li>pEp for Outlook as add-on for Microsoft Outlook, release <a href="#SRC.pepforoutlook" class="xref">[SRC.pepforoutlook]</a>
</li>
<li>pEp for Android (based on a fork of the K9 MUA), release <a href="#SRC.pepforandroid" class="xref">[SRC.pepforandroid]</a>
</li>
<li>Enigmail/pEp as add-on for Mozilla Thunderbird, release <a href="#SRC.enigmailpep" class="xref">[SRC.enigmailpep]</a>
</li>
<li>pEp for iOS (implemented in a new MUA), beta <a href="#SRC.pepforios" class="xref">[SRC.pepforios]</a>
</li>
</ul>
<p id="rfc.section.9.2.p.3">pEp for Android, iOS and Outlook are provided by pEp Security, a commercial entity specializing in end-user software implementing pEp while Enigmail/pEp is pursued as community project, supported by the pEp Foundation.</p>
<p id="rfc.section.9.2.p.4">All software is available as Free Software and published also in source form.</p>
<h1 id="rfc.section.10">
<a href="#rfc.section.10">10.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.10.p.1">The authors would like to thank the following people who have provided significant contributions or feedback for the development of this document: Krista Bennett, Volker Birk, Bernie Hoeneisen and Hernani Marques.</p>
<h1 id="rfc.references">
<a href="#rfc.references">11.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">11.1.</a> Normative 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.marques-pep-email">[I-D.marques-pep-email]</b></td>
<td class="top">
<a>Marques, H.</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-email-02">pretty Easy privacy (pEp): Email Formats and Protocols</a>", Internet-Draft draft-marques-pep-email-02, October 2018.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.melnikov-lamps-header-protection">[I-D.melnikov-lamps-header-protection]</b></td>
<td class="top">
<a>Melnikov, A.</a>, "<a href="https://tools.ietf.org/html/draft-melnikov-lamps-header-protection-00">Considerations for protecting Email header with S&#8203;/&#8203;MIME</a>", Internet-Draft draft-melnikov-lamps-header-protection-00, October 2018.</td>
</tr>
<tr>
<td class="reference"><b id="PGPMIME">[PGPMIME]</b></td>
<td class="top">
<a>Elkins, M.</a>, <a>Del Torto, D.</a>, <a>Levien, R.</a> and <a>T. Roessler</a>, "<a href="https://tools.ietf.org/html/rfc3156">MIME Security with OpenPGP</a>", RFC 3156, DOI 10.17487/RFC3156, August 2001.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2046">[RFC2046]</b></td>
<td class="top">
<a>Freed, N.</a> and <a>N. Borenstein</a>, "<a href="https://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>", RFC 2046, DOI 10.17487/RFC2046, November 1996.</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="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="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="RFC5322">[RFC5322]</b></td>
<td class="top">
<a>Resnick, P.</a>, "<a href="https://tools.ietf.org/html/rfc5322">Internet Message Format</a>", RFC 5322, DOI 10.17487/RFC5322, October 2008.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5490">[RFC5490]</b></td>
<td class="top">
<a>Melnikov, A.</a>, "<a href="https://tools.ietf.org/html/rfc5490">The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata</a>", RFC 5490, DOI 10.17487/RFC5490, March 2009.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6376">[RFC6376]</b></td>
<td class="top">
<a>Crocker, D.</a>, <a>Hansen, T.</a> and <a>M. Kucherawy</a>, "<a href="https://tools.ietf.org/html/rfc6376">DomainKeys Identified Mail (DKIM) Signatures</a>", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7208">[RFC7208]</b></td>
<td class="top">
<a>Kitterman, S.</a>, "<a href="https://tools.ietf.org/html/rfc7208">Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1</a>", RFC 7208, DOI 10.17487/RFC7208, April 2014.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7489">[RFC7489]</b></td>
<td class="top">
<a>Kucherawy, M.</a> and <a>E. Zwicky</a>, "<a href="https://tools.ietf.org/html/rfc7489">Domain-based Message Authentication, Reporting, and Conformance (DMARC)</a>", RFC 7489, DOI 10.17487/RFC7489, March 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8551">[RFC8551]</b></td>
<td class="top">
<a>Schaad, J.</a>, <a>Ramsdell, B.</a> and <a>S. Turner</a>, "<a href="https://tools.ietf.org/html/rfc8551">Secure/Multipurpose Internet Mail Extensions (S&#8203;/&#8203;MIME) Version 4.0 Message Specification</a>", RFC 8551, DOI 10.17487/RFC8551, April 2019.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">11.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC7942">[RFC7942]</b></td>
<td class="top">
<a>Sheffer, Y.</a> and <a>A. Farrel</a>, "<a href="https://tools.ietf.org/html/rfc7942">Improving Awareness of Running Code: The Implementation Status Section</a>", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.enigmailpep">[SRC.enigmailpep]</b></td>
<td class="top">"<a href="https://enigmail.net/index.php/en/download/source-code">Source code for Enigmail/pEp</a>", July 2019.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforandroid">[SRC.pepforandroid]</b></td>
<td class="top">"<a href="https://pep-security.lu/gitlab/android/pep">Source code for pEp for Android</a>", July 2019.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforios">[SRC.pepforios]</b></td>
<td class="top">"<a href="https://pep-security.ch/dev/repos/pEp_for_iOS/">Source code for pEp for iOS</a>", July 2019.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforoutlook">[SRC.pepforoutlook]</b></td>
<td class="top">"<a href="https://pep-security.lu/dev/repos/pEp_for_Outlook/">Source code for pEp for Outlook</a>", July 2019.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#about-pep-design-principles" id="about-pep-design-principles">About pEp Design Principles</a>
</h1>
<p id="rfc.section.A.p.1">pretty Easy privacy (pEp) is working on bringing state-of-the-art automatic cryptography known from areas like TLS to electronic mail (email) communication. pEp is determined to evolve the existing standards as fundamentally and comprehensively as needed to gain easy implementation and integration, and for easy use for regular Internet users. pEp for email wants to attain to good security practice while still retaining backward compatibility for implementations widespread.</p>
<p id="rfc.section.A.p.2">To provide the required stability as a foundation for good security practice, pEp for email defines a fixed MIME structure for its innermost message structure, so to remove most attack vectors which have permitted the numerous EFAIL vulnerabilities. (TBD: ref)</p>
<p id="rfc.section.A.p.3">Security comes just next after privacy in pEp, for which reason the application of signatures without encryption to messages in transit is not considered purposeful. pEp for email herein referenced, and further described in <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>, either expects to transfer messages in cleartext without signature or encryption, or transfer them encrypted and with enclosed signature and necessary public keys so that replies can be immediately upgraded to encrypted messages.</p>
<p id="rfc.section.A.p.4">The pEp message format is equivalent to the S&#8203;/&#8203;MIME standard in ensuring header protection, in that the whole message is protected instead, by wrapping it and providing cryptographic services to the whole original message. The pEp message format is different compared to the S&#8203;/&#8203;MIME standard in that the pEp protocols propose opportunistic End-to-End security and signature, by allowing the transport of the necessary public key material along with the original messages.</p>
<p id="rfc.section.A.p.5">For the purpose of allowing the insertion of such public keys, the root entity of the protected message is thus nested once more into an additional multipart/mixed MIME entity. The current pEp proposal is for PGP/MIME, while an extension to S&#8203;/&#8203;MIME is next.</p>
<p id="rfc.section.A.p.6">pEp&#8217;s proposal is strict in that it requires that the cryptographic services applied to the protected message MUST include encryption. It also mandates a fixed MIME structure for the protected message, which always MUST include a plaintext and optionally an HTML representation (if HTML is used) of the same message, and requires that all other optional elements to be eventually presented as attachments. Alternatively the whole protected message could represent in turn a wrapped pEp wrapper, which makes the message structure fully recursive on purpose (e.g., for the purpose of anonymization through onion routing).</p>
<p id="rfc.section.A.p.7">For the purpose of implementing mixnet routing for email, it is foreseen to nest pEp messages recursively. A protected message can in turn contain a protected message due for forwarding. This is for the purpose to increase privacy and counter the necessary leakage of plaintext addressing in the envelope of the email.</p>
<p id="rfc.section.A.p.8">The recursive nature of the pEp message format allows for the implementation of progressive disclosure of the necessary transport relevant header fields just as-needed to the next mail transport agents along the transmission path.</p>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
</h1>
<p id="rfc.section.B.p.1">[[ RFC Editor: This section is to be removed before publication ]]</p>
<p></p>
<ul>
<li>draft-luck-lamps-pep-header-protection-03 <ul>
<li>Remove Use Cases / Requirements sections (move to new doc)</li>
<li>Adjust title of the document</li>
<li>Added note on implementation done of forwarded=no</li>
</ul>
</li>
<li>draft-luck-lamps-pep-header-protection-02 <ul>
<li>Add Privacy and IANA Considerations sections</li>
<li>Added / Adjusted requirements</li>
</ul>
</li>
<li>draft-luck-lamps-pep-header-protection-01 <ul><li>Major rewrite and update of whole document</li></ul>
</li>
<li>draft-luck-lamps-pep-header-protection-00 <ul><li>Initial version</li></ul>
</li>
</ul>
<h1 id="rfc.appendix.C">
<a href="#rfc.appendix.C">Appendix C.</a> <a href="#open-issues" id="open-issues">Open Issues</a>
</h1>
<p id="rfc.section.C.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication. ]]</p>
<p></p>
<ul><li>Align with specification for MIME Content-Type message/partial <ul><li>We probably have issues and overlapping specifications about encoding for nested message/rfc822 entities, specified in <a href="#RFC2046" class="xref">[RFC2046]</a>. Further study is needed to find and understand the issues.</li></ul>
</li></ul>
<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Claudio Luck</span>
<span class="n hidden">
<span class="family-name">Luck</span>
</span>
</span>
<span class="org vcardline">pEp Foundation</span>
<span class="adr">
<span class="vcardline">Oberer Graben 4</span>
<span class="vcardline">
<span class="locality">CH-8400 Winterthur</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">Switzerland</span>
</span>
<span class="vcardline">EMail: <a href="mailto:claudio.luck@pep.foundation">claudio.luck@pep.foundation</a></span>
<span class="vcardline">URI: <a href="https://pep.foundation/">https://pep.foundation/</a></span>
</address>
</div>
</body>
</html>

+ 952
- 0
lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-03.txt View File

@ -0,0 +1,952 @@
Network Working Group C. Luck
Internet-Draft pEp Foundation
Intended status: Informational July 05, 2019
Expires: January 6, 2020
pretty Easy privacy (pEp): Progressive Header Disclosure
draft-luck-lamps-pep-header-protection-03
Abstract
Issues with email header protection in S/MIME have been recently
raised in the IETF LAMPS Working Group. The need for amendments to
the existing specification regarding header protection was expressed.
The pretty Easy privacy (pEp) implementations currently use a
mechanism quite similar to the currently standardized message
wrapping for S/MIME. The main difference is that pEp is using PGP/
MIME instead, and adds space for carrying public keys next to the
protected message.
In LAMPS, it has been expressed that whatever mechanism will be
chosen, it should not be limited to S/MIME, but also applicable to
PGP/MIME.
This document aims to contribute to this discussion and share the pEp
implementation experience with email header protection.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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/.
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."
This Internet-Draft will expire on January 6, 2020.
Luck Expires January 6, 2020 [Page 1]
Internet-Draft Progressive Header Disclosure July 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Message Format for Progressive Header Disclosure . . . . . . 4
2.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Inner Message . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Content-Type Parameter "forwarded" . . . . . . . . . . . 5
2.4. Outer Message . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Transport Message . . . . . . . . . . . . . . . . . . . . 8
2.6. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 9
3. Candidate Header Fields for Header Protection . . . . . . . . 9
4. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 9
5. Processing Incoming Email under Progressive Header Disclosure 10
5.1. Processing of Signed-only Email . . . . . . . . . . . . . 10
5.2. Incoming Filter Processing . . . . . . . . . . . . . . . 10
5.2.1. Staged Filtering of Inbound Messages . . . . . . . . 11
5.3. Outgoing Filter Processing . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Current software implementing pEp . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. About pEp Design Principles . . . . . . . . . . . . 15
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 16
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Luck Expires January 6, 2020 [Page 2]
Internet-Draft Progressive Header Disclosure July 2019
1. Introduction
A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the
email headers section, or selected header fields, but limited to a
domain-level perspective. Specifically these are DomainKeys
Identified Mail (DKIM) [RFC6376] and Sender Policy Framework (SPF)
[RFC7208] and Domain-based Message Authentication, Reporting, and
Conformance (DMARC) [RFC7489]. These protocols, while essential to
responding to a range of attacks on email, do not offer full End-to-
End protection to the headers section and are not capable of
providing privacy regarding the information represented therein.
The need for means of Data Minimization, which includes data
spareness and hiding of all information technically hideable, has
grown in importance over the past years.
A standard for End-to-End protection of the email headers section
exists for S/MIME since version 3.1. (cf. [RFC8551]):
In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services
to these header fields.
No mechanism for header protection has been standardized for
[PGPMIME] yet.
End-to-End protection for the email headers section is currently not
widely implemented - neither for messages protected by means of
S/MIME nor PGP/MIME. At least two variants of header protection are
known to be implemented. A recently submitted Internet-Draft
[I-D.melnikov-lamps-header-protection] discusses the two variants and
the challenges with header protection for S/MIME. The two variants
are referred to as:
o Option 1: Memory Hole
o Option 2: Wrapping with message/rfc822 or message/global
pEp (pretty Easy privacy) [I-D.birk-pep] for email
[I-D.marques-pep-email] already implements an option quite similar to
Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 2,
ff.). Existing implementations of pEp have also added inbound
support for "Memory Hole" referred to above as Option 1, thus being
able to study the differences and the implementator's challenges.
Luck Expires January 6, 2020 [Page 3]
Internet-Draft Progressive Header Disclosure July 2019
pEp now also supports the "forwarded=no" attribute proposed in
[I-D.melnikov-lamps-header-protection], and further described in
Section 2.3.
Interoperability and implementation symmetry between PGP/MIME and
S/MIME is planned by pEp, but still in an early stage of development.
This document describes Progressive Header Disclosure as implemented
in the "pEp message format version 2". This format inherently offers
header protection as a side effect, but is only intended for use only
with signed-and-encrypted messages. The feature of protecting
headers may be used independently by mail user agents otherwise not
wanting to conform to pEp standards (Section 2, ff.).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terms
The following terms are defined for the scope of this document:
o Man-in-the-middle attack (MITM): cf. [RFC4949]
2. Message Format for Progressive Header Disclosure
2.1. Compatibility
The pEp message format version 2 is designed such that a receiving
Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-
compliant, still has built-in capability to properly verify the
integrity of the mail, decode it and display all information of the
original mail to the user. The recovered protected message is
selfsufficiently described, including all protected header fields.
The pEp message format version 2 (as used by all the various pEp
implementations, cf. Section 9) is similar to what is standardized
for S/MIME in [RFC8551]:
In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services
to these header fields. It is up to the receiving client to
decide how to present this "inner" header along with the
unprotected "outer" header.
Luck Expires January 6, 2020 [Page 4]
Internet-Draft Progressive Header Disclosure July 2019
When an S/MIME message is received, if the top-level protected
MIME entity has a Content-Type of message/rfc822, it can be
assumed that the intent was to provide header protection. This
entity SHOULD be presented as the top-level message, [...].
2.2. Inner Message
*Note*: this section is for your information only. It does not add
requirements for the header protection feature to work.
The pEp message format requires the innermost protected message to
follow a fixed MIME structure and to consist of exactly one human-
readable message which is represented in plain or HTML format. Both
plain and html entities MUST represent the same message to the user.
Any attachment to the message must be laid out in a flat list. No
additional multipart entities are allowed in the pEp message.
These restrictions permit to build mail user agents which are immune
to the EFAIL attacks.
This message is herein further referred to as the "pEp inner
message".
A mail user agent wanting to follow this standard, SHOULD transform
any "original message" into a "pEp inner message" for safe
representation on the receiving side.
2.3. Content-Type Parameter "forwarded"
One caveat of the design is that the user interaction with message/
rfc822 entities varies considerably across different mail user
agents. No standard is currently available which enables MUAs to
reliably determine whenever a nested message/rfc822 entity is meant
to blend the containing message, or if it was effectively intended to
be forwarded as a file document. pEp currently implements the
proposal described by [I-D.melnikov-lamps-header-protection], 3.2,
which defines a new Content-Type header field parameter with name
"forwarded", for the MUA to distinguish between a forwarded message
and a nested message for the purpose of header protection, i.e.,
using "forwarded=no".
2.4. Outer Message
With pEp message format version 2, the pEp standardized message is
equally wrapped in a message/rfc822 entity, but this time being in
turn wrapped in a multipart/mixed entity. The purpose of the
additional nesting is to allow for public keys of the sender to be
Luck Expires January 6, 2020 [Page 5]
Internet-Draft Progressive Header Disclosure July 2019
stored alongside the original message while being protected by the
same mechanism.
For the case of PGP/MIME, the currently only implemented MIME
encryption protocol implemented in pEp, the top-level entity called
the "outer message" MUST contain:
o exactly one entity of type message/rfc822, and
o one or more entity of type application/pgp-keys
Notes on the current pEp client implementations:
o the current pEp implementation also adds a text/plain entity
containing "pEp-Wrapped-Message-Info: OUTER" as first element in
the MIME tree. This element is not strictly necessary, but is in
place for better backwards compatibility when manually navigating
the nested message structure. This is part of the study of
various solutions to maximize backwards compatibility, and has
been omitted from the following examples.
o the current pEp implementation prepends "pEp-Wrapped-Message-Info:
INNER<CR><LF>" to the original message body. This is an
implementation detail which should be ignored, and has been
omitted in the following examples.
o the current pEp implementation may render a text/plain directly in
place of the multipart/alternate, when no HTML representation was
generated by the sending MUA. This is not strict according to
pEp's own specification, and is currently being investigated.
This is an example of the top-level MIME entity, before being
encrypted and signed:
Luck Expires January 6, 2020 [Page 6]
Internet-Draft Progressive Header Disclosure July 2019
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="6b8b4567327b23c6643c986966334873"
--6b8b4567327b23c6643c986966334873
Content-Type: message/rfc822; forwarded="no"
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Example
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
X-Pep-Version: 2.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
--29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="msg.txt"
p=E2=89=A1p for Privacy by Default.
-- =20
Sent from my p=E2=89=A1p for Android.
--29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
p=E2=89=A1p for Privacy by Default.<br>
-- <br>
Sent from my p=E2=89=A1p for Android.<br>
--29fe9d2b2d7f6a703c1bffc47c162a8c--
--6b8b4567327b23c6643c986966334873
Content-Type: application/pgp-keys
Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----
--6b8b4567327b23c6643c986966334873--
Luck Expires January 6, 2020 [Page 7]
Internet-Draft Progressive Header Disclosure July 2019
2.5. Transport Message
In pEp message format 2 the "outer message" consists of a full RFC822
message with body and a minimal set of header fields, just those
necessary to conform to MIME multipart standards.
The "outer message" should be encrypted and carry a signature
according to the MIME encryption standards. The resulting message is
the transport message which a root entity of type multipart/
encrypted.
A minimal set of header fields should be set on the "transport
message", as to permit delivery, without disclosing private
information.
The structure of the transport message may be altered in-transit,
e.g. through mailing list agents, or inspection gateways.
Signing and encrypting a message with MIME Security with [PGPMIME],
yields a message with the following complete MIME structure, seen
across the encryption layer:
= multipart/encrypted; protocol="application/pgp-encrypted";
+ application/pgp-encrypted [ Version: 1 ]
+ application/octet-stream; name="msg.asc"
{
Content-Disposition: inline; filename="msg.asc";
}
|
[ opaque encrypted structure ]
|
{ minimal headers }
+ multipart/mixed
+ message/rfc822; forwarded="no";
|
{ protected message headers }
+ multipart/mixed
+ multipart/alternate
+ text/plain
+ text/html
+ application/octet-stream [ attachmet_1 ]
+ application/octet-stream [ attachmet_2 ]
+ application/pgp-keys
The header fields of the sub-part of type application/octet-stream
SHOULD be modified to ensure that:
Luck Expires January 6, 2020 [Page 8]
Internet-Draft Progressive Header Disclosure July 2019
o the Content-Type header field's
* "name" parameter is set to the value "msg.asc", and
* parameter "forwarded" is set to "no", and
o the Content-Disposition header field value is set to "inline"
* and the "filename" parameter is set to "msg.asc".
2.6. S/MIME Compatibility
Interoperability and implementation symmetry between PGP/MIME and
S/MIME is on the roadmap of pEp.
3. Candidate Header Fields for Header Protection
By default, all headers of the original message SHOULD be wrapped
with the original message, with one exception:
o the header field "Bcc" MUST NOT be added to the protected headers.
4. Stub Outside Headers
The outer message requires a minimal set of headers to be in place
for being eligible for transport. This includes the "From", "To",
"Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol
hereby defined also depends on the "MIME-Version", "Content-Type",
"Content-Disposition" and eventually the "Content-Transport-Encoding"
header field to be present.
Submission and forwarding based on SMTP carries "from" and
"receivers" information out-of-band, so that the "From" and "To"
header fields are not strictly necessary. Nevertheless, "From",
"Date", and at least one destination header field is mandatory as per
[RFC5322]. They SHOULD be conserved for reliability.
The following header fields should contain a verbatim copy of the
header fields of the inner message:
o Date
o From
o To
o Cc (*)
Luck Expires January 6, 2020 [Page 9]
Internet-Draft Progressive Header Disclosure July 2019
o Bcc (*)
The entries with an asterisk mark (*) should only be set if also
present in the original message.
Clients which follow pEp standards MUST set the header field value
for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which
do not adhere to all pEp standards should set the header field value
of "Subject" to a descriptive stub value. An example used in
practice is
o Subject: Encrypted message
The following header fields MUST be initialized with proper values
according to the MIME standards:
o Content-Type
o Content-Disposition
o Content-Transport-Encoding (if necessary)
5. Processing Incoming Email under Progressive Header Disclosure
[[ TODO ]]
5.1. Processing of Signed-only Email
pEp either engages in a signed-and-encrypted communication or in an
unsigned plaintext communication. Inbound signatures attached to
plaintext messages are duly verified but cannot enhance the perceived
quality of the message in the user interface (while an invalid
signature degrades the perception) [I-D.birk-pep].
5.2. Incoming Filter Processing
The Mail User Agent may implement outgoing filtering of mails, which
may veto, alter, redirect or replicate the messages. The
functionality may be implemented on the mailbox server and be
configurable through a well-known protocol, e.g., by means of The
Sieve Mail-Filtering Language [RFC5490], or be implemented client-
side, or in a combination of both.
A mailbox server, which is required to process the full range of
possible filters, is requiring plaintext access to the header fields.
In an End-to-End-encryption context, which pEp enforces by default,
upon first reception of the message the mailbox server is limited to
Luck Expires January 6, 2020 [Page 10]
Internet-Draft Progressive Header Disclosure July 2019
see the transport- relevant headers of the outer wrapper message. A
pEp client configured to trust the server ("trusted server" setting
[I-D.marques-pep-email]) will later download the encrypted message,
decrypt it and replace the copy on the server by the decrypted copy.
5.2.1. Staged Filtering of Inbound Messages
Inbound messages are expected to be delivered to the inbox while
still being encrypted. At this point in time, server-side filtering
can only evaluate the unprotected header fields in the wrapper
message.
In an End-to-End-encryption context, which pEp enforces by default,
the mailbox server is limited to see the transport-relevant headers
of the outer wrapper message only upon first delivery. A pEp client
configured to trust the server ("trusted server" setting
[I-D.marques-pep-email]) will eventually download the encrypted
message, decrypt it locally and replace the copy on the server by the
decrypted copy. Server-side message filters SHOULD be able to detect
such post-processed messages, and apply the pending filters. The
client SHOULD easily reflect the post-filtered messages in the user
interface.
5.3. Outgoing Filter Processing
The Mail User Agent may implement outgoing filtering of emails, which
may veto, alter or replicate the email. They may also hint the MUA
to store a copy in an alternate "Sent" folder.
Filters which veto the sending or do alter the mail or replicate it
(e.g., mass-mail generators) SHOULD be completed prior to applying
protection, and thus also prior to applying header protection.
Redirection to alternate "Sent" folders MUST NOT be decided prior to
applying protection, but MUAs MAY abide from this restriction if they
implement the "trusted server" option and the option is selected for
the specific mailbox server; in this case, MUAs MUST NOT allow to
redirect a message to an untrusted server by these rules, to prevent
information leakage to the untrusted server.
[[ TODO: Mention implicit filter for minimal color-rating for message
replication. ]]
[[ TODO: How to produce key-export-mails manually this way? That is,
what about non-pEp-mode? ]]
Luck Expires January 6, 2020 [Page 11]
Internet-Draft Progressive Header Disclosure July 2019
6. Security Considerations
[[ TODO ]]
7. Privacy Considerations
[[ TODO ]]
8. IANA Considerations
This document has no actions for IANA.
9. Implementation Status
9.1. Introduction
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "[...] this will allow reviewers and working
groups to assign due consideration to documents that have the benefit
of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit."
9.2. Current software implementing pEp
The following software implementing the pEp protocols (to varying
degrees) already exists:
o pEp for Outlook as add-on for Microsoft Outlook, release
[SRC.pepforoutlook]
o pEp for Android (based on a fork of the K9 MUA), release
[SRC.pepforandroid]
Luck Expires January 6, 2020 [Page 12]
Internet-Draft Progressive Header Disclosure July 2019
o Enigmail/pEp as add-on for Mozilla Thunderbird, release
[SRC.enigmailpep]
o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
pEp for Android, iOS and Outlook are provided by pEp Security, a
commercial entity specializing in end-user software implementing pEp
while Enigmail/pEp is pursued as community project, supported by the
pEp Foundation.
All software is available as Free Software and published also in
source form.
10. Acknowledgements
The authors would like to thank the following people who have
provided significant contributions or feedback for the development of