juga
/
internet-drafts
forked from pEp.foundation/internet-drafts
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
mixnet
master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '65b30c8cfc'
${ noResults }
internet-drafts/ietf-lamps-hp/review/draft-ietf-lamps-header-pro...

1198 lines
66 KiB
HTML
Raw Normal View History Unescape Escape

review version with partial implementation of feedback from Alexey
3 years ago
<!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>Header Protection for S&#8288;/&#8288;MIME</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 Problem Statement">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Privacy">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Security">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Usability">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Interoperability">
<link href="#rfc.section.3" rel="Chapter" title="3 Use Cases">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Interactions">
<link href="#rfc.section.3.1.1" rel="Chapter" title="3.1.1 Main Case for Header Protection">
<link href="#rfc.section.3.1.2" rel="Chapter" title="3.1.2 Backward Compatibility">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Protection Levels">
<link href="#rfc.section.4" rel="Chapter" title="4 Specification">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Main Use Case">
<link href="#rfc.section.4.1.1" rel="Chapter" title="4.1.1 MIME Format">
<link href="#rfc.section.4.1.2" rel="Chapter" title="4.1.2 Inner Message Header Fields">
<link href="#rfc.section.4.1.3" rel="Chapter" title="4.1.3 Wrapper">
<link href="#rfc.section.4.1.4" rel="Chapter" title="4.1.4 Outer Message Header Fields">
<link href="#rfc.section.4.1.5" rel="Chapter" title="4.1.5 Receiving User Facing Message Header Fields">
<link href="#rfc.section.4.1.6" rel="Chapter" title="4.1.6 Header Field Flow">
<link href="#rfc.section.4.1.7" rel="Chapter" title="4.1.7 Sending Side Message Processing">
<link href="#rfc.section.4.1.8" rel="Chapter" title="4.1.8 Receiving Side Message Processing">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Backward Compatibility Use Case">
<link href="#rfc.section.5" rel="Chapter" title="5 Security Considerations">
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.section.8" rel="Chapter" title="8 Acknowledgments">
<link href="#rfc.references" rel="Chapter" title="9 References">
<link href="#rfc.references.1" rel="Chapter" title="9.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="9.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Additional information">
<link href="#rfc.appendix.A.1" rel="Chapter" title="A.1 Stored Variants of Messages with Bcc">
<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.40.0 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Hoeneisen, B. and A. Melnikov" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-lamps-header-protection-00" />
<meta name="dct.issued" scheme="ISO8601" content="2020-07-04" />
<meta name="dct.abstract" content="Privacy and security issues with email header protection in S&#8288;/&#8288;MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S&#8288;/&#8288;MIME specification is to be updated regarding header protection. This document describes the problem statement, generic use cases, and the S&#8288;/&#8288;MIME specification for header protection. " />
<meta name="description" content="Privacy and security issues with email header protection in S&#8288;/&#8288;MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S&#8288;/&#8288;MIME specification is to be updated regarding header protection. This document describes the problem statement, generic use cases, and the S&#8288;/&#8288;MIME specification for header protection. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">B. Hoeneisen</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">A. Melnikov</td>
</tr>
<tr>
<td class="left">Expires: January 5, 2021</td>
<td class="right">Isode Ltd</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 04, 2020</td>
</tr>
</tbody>
</table>
<p class="title">Header Protection for S&#8288;/&#8288;MIME<br />
<span class="filename">draft-ietf-lamps-header-protection-00</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>Privacy and security issues with email header protection in S&#8288;/&#8288;MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S&#8288;/&#8288;MIME specification is to be updated regarding header protection.</p>
<p>This document describes the problem statement, generic use cases, and the S&#8288;/&#8288;MIME specification for 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 5, 2021.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2020 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">Problem Statement</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Privacy</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Security</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">Usability</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Interoperability</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Use Cases</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Interactions</a>
</li>
<ul><li>3.1.1. <a href="#rfc.section.3.1.1">Main Case for Header Protection</a>
</li>
<li>3.1.2. <a href="#rfc.section.3.1.2">Backward Compatibility</a>
</li>
</ul><li>3.2. <a href="#rfc.section.3.2">Protection Levels</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Specification</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Main Use Case</a>
</li>
<ul><li>4.1.1. <a href="#rfc.section.4.1.1">MIME Format</a>
</li>
<li>4.1.2. <a href="#rfc.section.4.1.2">Inner Message Header Fields</a>
</li>
<li>4.1.3. <a href="#rfc.section.4.1.3">Wrapper</a>
</li>
<li>4.1.4. <a href="#rfc.section.4.1.4">Outer Message Header Fields</a>
</li>
<li>4.1.5. <a href="#rfc.section.4.1.5">Receiving User Facing Message Header Fields</a>
</li>
<li>4.1.6. <a href="#rfc.section.4.1.6">Header Field Flow</a>
</li>
<li>4.1.7. <a href="#rfc.section.4.1.7">Sending Side Message Processing</a>
</li>
<li>4.1.8. <a href="#rfc.section.4.1.8">Receiving Side Message Processing</a>
</li>
</ul><li>4.2. <a href="#rfc.section.4.2">Backward Compatibility Use Case</a>
</li>
</ul><li>5. <a href="#rfc.section.5">Security Considerations</a>
</li>
<li>6. <a href="#rfc.section.6">Privacy Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a>
</li>
<li>8. <a href="#rfc.section.8">Acknowledgments</a>
</li>
<li>9. <a href="#rfc.references">References</a>
</li>
<ul><li>9.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>9.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Additional information</a>
</li>
<ul><li>A.1. <a href="#rfc.appendix.A.1">Stored Variants of Messages with Bcc</a>
</li>
</ul><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">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 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 (HF) from the domain-level perspective, specifically 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 header section and are not capable of providing privacy for the information contained therein.</p>
<p id="rfc.section.1.p.2">The need for means of Data Minimization, which includes data spareness and hiding all technically concealable information whenever possible, has grown in importance over the past several years.</p>
<p id="rfc.section.1.p.3">A standard for end-to-end protection of the email header section exists for S&#8288;/&#8288;MIME version 3.1 and later. (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&#8288;/&#8288;MIME security services to these header fields.</li></ul>
<p id="rfc.section.1.p.5">No mechanism for header protection (HP) has been standardized for PGP/MIME (Pretty Good Privacy) <a href="#RFC3156" class="xref">[RFC3156]</a> yet.</p>
<p id="rfc.section.1.p.6">Several varying implementations of end-to-end protections for email header sections exist, though the total number of such implementations appears to be rather low.</p>
<p id="rfc.section.1.p.7">Some LAMPS WG participants expressed the opinion that whatever mechanism will be chosen, it should not be limited to S&#8288;/&#8288;MIME, but also applicable to PGP/MIME.</p>
<p id="rfc.section.1.p.8">This document describes the problem statement (<a href="#problem-statement" class="xref">Section 2</a>), generic use cases (<a href="#use-cases" class="xref">Section 3</a>) and the specification for Header Protection (<a href="#specification" class="xref">Section 4</a>).</p>
<p><a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a> defines the requirements that this specification is based on.</p>
<p id="rfc.section.1.p.10">This document is in early draft state and contains a proposal to base the upcoming discussions on. In any case, the final solution is to be determined by the IETF LAMPS WG.</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 (MITM) attack: cf. <a href="#RFC4949" class="xref">[RFC4949]</a>, which states: &#8220;A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association.&#8221;</li>
<li>S&#8288;/&#8288;MIME: Secure/Multipurpose Internet Mail Extensions (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>)</li>
<li>PGP/MIME: MIME Security with OpenPGP (cf. <a href="#RFC3156" class="xref">[RFC3156]</a>)</li>
<li>Message: An Email Message consisting of header fields (collectively called &#8220;the Header Section of the message&#8221;) followed, optionally, by a Body; cf. <a href="#RFC5322" class="xref">[RFC5322]</a>.</li>
<li>Transport: The entity taking care of the transport of a Message towards the receiver or from the sender. The Transport on the sending side typically determines the destination recipients by reading the To, Cc and Bcc Header Fields (of the Outer Message). The Transport is typically implemented by an MTA (Mail Transfer Agent).</li>
<li>Header Field (HF): cf. <a href="#RFC5322" class="xref">[RFC5322]</a> Header Fields are lines beginning with a field name, followed by a colon (&#8220;:&#8221;), followed by a field body (value), and terminated by CRLF; cf. <a href="#RFC5322" class="xref">[RFC5322]</a>. <br><br> Note: To avoid ambiguity, this document does not use the terms &#8220;Header&#8221; or &#8220;Headers&#8221; in isolation, but instead always uses &#8220;Header Field&#8221; to refer to the individual field and &#8220;Header Section&#8221; to refer to the entire collection; cf. <a href="#RFC5322" class="xref">[RFC5322]</a>.</li>
<li>Header Section (HS): The Header Section is a sequence of lines of characters with special syntax as defined in <a href="#RFC5322" class="xref">[RFC5322]</a>. It is the (top) section of a message containing the Header Fields.</li>
<li>Body: The Body is simply a sequence of characters that follows the Header Section and is separated from the Header Section by an empty line (i.e., a line with nothing preceding the CRLF); cf <a href="#RFC5322" class="xref">[RFC5322]</a>. It is the (bottom) section of Message containing the payload of a Message. Typically, the Body consists of a (multipart) MIME <a href="#RFC2045" class="xref">[RFC2045]</a> construct.</li>
<li>MIME Header Fields: Header Fields describing content of a MIME entity <a href="#RFC2045" class="xref">[RFC2045]</a>, in particular the MIME structure. Each MIME Header Field name starts with &#8220;Content-&#8220; prefix.</li>
<li>MIME Header Section (part): The collection of MIME Header Fields. &#8220;MIME Header Section&#8221; refers to a Header Sections that contains only MIME Header Fields, whereas &#8220;MIME Header Section part&#8221; refers to the MIME Header Fields of a Header Section that - in addition to MIME Header Fields - also contains non-MIME Header Fields.</li>
<li>Header Protection (HP): cryptographic protection of email Header Sections (or parts of it) for signatures and/or encryption</li>
<li>Protection Levels (PL): One of &#8216;signature and encryption&#8217;, &#8216;signature only&#8217; or &#8216;encryption only&#8217; (cf. <a href="#protection-levels" class="xref">Section 3.2</a>)</li>
</ul>
<p></p>
<ul>
<li>Original Message (OrigM): The message to be protected before any protection related processing has been applied on the sending side.</li>
<li>Inner Message (InnerM): The message to be protected, i.e. which wrapping and protection measures are applied to on the sending side or the result of decryption and unwrapping on the receiving side respectively. Typically, the Inner Message is in clear text. The Inner Message is a subset of (or the same as) the Original Message (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>). The Inner Message must be the same on the sending and the receiving side.</li>
<li>Outer Message (OuterM): The Message as handed over to the Transport or received from the Transport respectively. The Outer Message normally differs on the sending and the receiving side (e.g. new Header Fields are added by intermediary nodes).</li>
<li>Receiving User Facing Message (RUFM): The message used for rendering at the receiving side after the Outer Message Header Section has been merged with the Inner Message Header Section.</li>
<li>Essential Header Fields (EHF): The minimum set of Header Fields an Outer Message Header Section SHOULD contain; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.4</a>.</li>
<li>Protected: Protected refers to the parts of a message where protection measures of any Protection Level have been applied to.</li>
<li>Protected Message: A message that protection measures of any Protection Levels have been applied to.</li>
<li>Unprotected: Unprotected refers to the parts of a message where no protection measures of any Protection Levels have been applied to.</li>
<li>Unprotected Message: A message that no protection measures of any Protection Levels have been applied to.</li>
<li>Data Minimization: Data spareness and hiding of all technically concealable information whenever possible.</li>
</ul>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#problem-statement" id="problem-statement">Problem Statement</a>
</h1>
<p id="rfc.section.2.p.1">The LAMPS charter contains the following Work Item:</p>
<p></p>
<ul class="empty"><li>Update the specification for the cryptographic protection of email headers &#8211; both for signatures and encryption &#8211; to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages.</li></ul>
<p id="rfc.section.2.p.3">In the following a set of challenges to be addressed:</p>
<p id="rfc.section.2.p.4">[[ TODO: enhance this section, add more items to the following ]]</p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#privacy" id="privacy">Privacy</a>
</h1>
<p></p>
<ul><li>Data Minimization, which includes data spareness and hiding all technically concealable information whenever possible</li></ul>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#security" id="security">Security</a>
</h1>
<p></p>
<ul><li>MITM attacks (cf. <a href="#RFC4949" class="xref">[RFC4949]</a>)</li></ul>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#usability" id="usability">Usability</a>
</h1>
<p></p>
<ul><li>User interaction / User experience</li></ul>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#interoperability" id="interoperability">Interoperability</a>
</h1>
<p></p>
<ul><li>Interoperability with <a href="#RFC8551" class="xref">[RFC8551]</a> implementations</li></ul>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#use-cases" id="use-cases">Use Cases</a>
</h1>
<p id="rfc.section.3.p.1">In the following, the reader can find a list of the generic use cases that need to be addressed for messages with Header Protection (HP). These use cases apply independently of whether S&#8288;/&#8288;MIME, PGP/MIME or any other technology is used to achieve HP.</p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#interactions" id="interactions">Interactions</a>
</h1>
<h1 id="rfc.section.3.1.1">
<a href="#rfc.section.3.1.1">3.1.1.</a> <a href="#main-case-for-header-protection" id="main-case-for-header-protection">Main Case for Header Protection</a>
</h1>
<p id="rfc.section.3.1.1.p.1">Both peers (sending and receiving side) fully support Header Protection as specified in this document or the receiving side is at least compliant with the MIME specification <a href="#RFC2045" class="xref">[RFC2045]</a>, ff.; cf. <a href="#main-use-case" class="xref">Section 4.1</a>.</p>
<h1 id="rfc.section.3.1.2">
<a href="#rfc.section.3.1.2">3.1.2.</a> <a href="#backward-compatibility" id="backward-compatibility">Backward Compatibility</a>
</h1>
<p id="rfc.section.3.1.2.p.1">The sending side fully supports Header protection as specified in this document, while the receiving side does not support the MIME specification <a href="#RFC2045" class="xref">[RFC2045]</a>, ff. correctly; see <a href="#backward-compatibility-use-case" class="xref">Section 4.2</a>.</p>
<p id="rfc.section.3.1.2.p.2">Note: The compatibility of legacy HP systems with this new solutions, and how to handle issues surrounding future maintenance for these legacy systems, will be decided by the LAMPS WG.</p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#protection-levels" id="protection-levels">Protection Levels</a>
</h1>
<p id="rfc.section.3.2.p.1">The following protection levels need to be considered:</p>
<p id="rfc.section.3.2.p.2">a) Signature and encryption</p>
<pre>
Messages containing a cryptographic signature, which are also
encrypted.
</pre>
<p id="rfc.section.3.2.p.3">b) Signature only</p>
<pre>
Messages containing a cryptographic signature, but which are not
encrypted.
</pre>
<p id="rfc.section.3.2.p.4">c) Encryption only</p>
<pre>
Messages that are encrypted, but do not contain a cryptographic
signature.
</pre>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#specification" id="specification">Specification</a>
</h1>
<p id="rfc.section.4.p.1">This section contains the specification for Header Protection in S&#8288;/&#8288;MIME to update and clarifies Section 3.1 of <a href="#RFC8551" class="xref">[RFC8551]</a> (S&#8288;/&#8288;MIME 4.0).</p>
<p id="rfc.section.4.p.2">Furthermore, it is likely that PGP/MIME <a href="#RFC3156" class="xref">[RFC3156]</a> will also incorprorate this specification or parts of it.</p>
<p id="rfc.section.4.p.3">This specification applies to the protection levels &#8220;signature &amp; encryption&#8221; and &#8220;signature only&#8221; (cf. <a href="#protection-levels" class="xref">Section 3.2</a>):</p>
<p id="rfc.section.4.p.4">Sending and receiving sides MUST implement &#8220;signature and encryption&#8221;, which is the default to use on the sending side.</p>
<p id="rfc.section.4.p.5">Certain implementations MAY decide to send &#8220;signature only&#8221; messages, depending on the circumstances and customer requirements. Sending side MAY and receiving sides MUST implement &#8220;signature only&#8221;.</p>
<p id="rfc.section.4.p.6">It generally is NOT RECOMMENDED to send a message with protection level &#8220;encryption only&#8221;. On the other hand, messages with protection level &#8220;encryption only&#8221; might arrive at the receiving side. While not targeted to protection level &#8220;encryption only&#8221;, this specification is assumed to also function for &#8220;encryption only&#8221;. Receiving sides SHOULD implement &#8220;encryption only&#8221;.</p>
<p id="rfc.section.4.p.7">Note: It is for further study whether or not more guidance for handling messages with protection level &#8220;encryption only&#8221; at the receiving side is needed.</p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#main-use-case" id="main-use-case">Main Use Case</a>
</h1>
<p id="rfc.section.4.1.p.1">This section applies to the Interaction (cf. <a href="#interactions" class="xref">Section 3.1</a>), where all involved parties (sending and receiving side) implement this specification or the receiving side is at least compliant with the MIME specification <a href="#RFC2045" class="xref">[RFC2045]</a>, ff. (For backward compatibility cases cf. <a href="#backward-compatibility-use-case" class="xref">Section 4.2</a>).</p>
<h1 id="rfc.section.4.1.1">
<a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#mime-format" id="mime-format">MIME Format</a>
</h1>
<p id="rfc.section.4.1.1.p.1">Currently there are two options in discussion:</p>
<p></p>
<ol>
<li>The option according to the current S&#8288;/&#8288;MIME specification (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>)</li>
<li>An alternative option that is based on the former &#8220;memory hole&#8221; approach (cf. <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>)</li>
</ol>
<h1 id="rfc.section.4.1.1.1">
<a href="#rfc.section.4.1.1.1">4.1.1.1.</a> <a href="#option-smime-spec" id="option-smime-spec">S/MIME Specification</a>
</h1>
<p id="rfc.section.4.1.1.1.p.1">As per S&#8288;/&#8288;MIME version 3.1 and later (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>), the sending client MAY wrap a full MIME message in a message/RFC822 wrapper in order to apply S&#8288;/&#8288;MIME security services to these header fields.</p>
<p id="rfc.section.4.1.1.1.p.2">To help the receiving side to distinguish between forwarded and wrapped message, a Content-Type header field parameter &#8220;forwarded&#8221; is added as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>. Certain mailing applications might display the Inner Message as attachment otherwise.</p>
<p id="rfc.section.4.1.1.1.p.3">The MIME structure of an Email message looks as follows:</p>
<pre>
&lt;Outer Message Header Section (unprotected)&gt;
&lt;Outer Message Body (protected)&gt;
&lt;MIME Header Section (wrapper)&gt;
&lt;Inner Message Header Section&gt;
&lt;Inner Message Body&gt;
</pre>
<p id="rfc.section.4.1.1.1.p.4">The following example demonstrates how header section and payload of a protected body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by &#8220;O: &#8220; are the Outer Message Header Section. Lines prepended by &#8220;I: &#8220; are the Inner Message Header Section. Lines prepended by &#8220;W: &#8220; are the wrapper (MIME Header Section):</p>
<pre>
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
O: To: somebody@example.net
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
W: Content-Type: message/RFC822; forwarded=no
W:
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
I: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
</pre>
<p id="rfc.section.4.1.1.1.p.5">The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the wrapper (MIME Header Section) and the Inner Message (Header Section and Body).</p>
<p id="rfc.section.4.1.1.1.p.6">The wrapper is a simple MIME Header Section with media type &#8220;message/RFC822&#8221; containing a Content-Type header field parameter &#8220;forwarded=no&#8221; followed by an empty line.</p>
<p id="rfc.section.4.1.1.1.p.7">The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>).</p>
<p id="rfc.section.4.1.1.1.p.8">The Inner Message Body is the same as the Original Message Body.</p>
<p id="rfc.section.4.1.1.1.p.9">The Original Message itself may contain any MIME structure.</p>
<h1 id="rfc.section.4.1.1.2">
<a href="#rfc.section.4.1.1.2">4.1.1.2.</a> <a href="#option-ex-memory-hole" id="option-ex-memory-hole">Alternative Option Autocrypt &#8220;Protected Headers&#8221; (Ex-&#8220;Memory Hole&#8221;)</a>
</h1>
<p id="rfc.section.4.1.1.2.p.1">An alternative option (based on the former autocrypt &#8220;Memory Hole&#8221; approach) to be considered, is described in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>.</p>
<p id="rfc.section.4.1.1.2.p.2">Unlike the option described in <a href="#option-smime-spec" class="xref">Section 4.1.1.1</a>, this option does not use a &#8220;message/RFC822&#8221; wrapper to unambigously delimit the Inner Message.</p>
<p id="rfc.section.4.1.1.2.p.3">Note: it is for further study, whether or not this option is (fully) compliant with the MIME standard, in particuar also <a href="#RFC2046" class="xref">[RFC2046]</a>, Section 5.1. (Multipart Media Type).</p>
<p id="rfc.section.4.1.1.2.p.4">The MIME structure of an Email message looks as follows:</p>
<pre>
&lt;Outer Message Header Section (unprotected)&gt;
&lt;Outer Message Body (protected)&gt;
&lt;Inner Message Header Section&gt;
&lt;Inner Message Body&gt;
</pre>
<p id="rfc.section.4.1.1.2.p.5">The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by &#8220;O: &#8220; are the outer header section. Lines prepended by &#8220;I: &#8220; are the inner header section.</p>
<pre>
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
I: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
</pre>
<p id="rfc.section.4.1.1.2.p.6">The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the Inner Message (Header Section and Body).</p>
<p id="rfc.section.4.1.1.2.p.7">The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>).</p>
<p id="rfc.section.4.1.1.2.p.8">The Inner Message Body is the same as the Original Message Body.</p>
<p id="rfc.section.4.1.1.2.p.9">The Original Message itself may contain any MIME structure.</p>
<h1 id="rfc.section.4.1.2">
<a href="#rfc.section.4.1.2">4.1.2.</a> <a href="#inner-msg-hf" id="inner-msg-hf">Inner Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.2.p.1">It is RECOMMEND that the Inner Messages contains all the Header Fields of the Original Message with the exception of the following Header Field, which MUST NOT be included to the Inner Message nor to any other protected part of the message:</p>
<p></p>
<ul><li>Bcc</li></ul>
<p id="rfc.section.4.1.2.p.3">[[ TODO: Bcc handling needs to be further specified (see also <a href="#bcc-handling" class="xref">Appendix A.1</a>). Certain MUAs cannot properly decrypt messages with Bcc recipients. ]]</p>
<h1 id="rfc.section.4.1.3">
<a href="#rfc.section.4.1.3">4.1.3.</a> <a href="#wrapper" id="wrapper">Wrapper</a>
</h1>
<p id="rfc.section.4.1.3.p.1">The wrapper is a simple MIME Header Section followed by an empty line preceding the Inner Message (inside the Outer Message Body). The media type of the wrapper MUST be &#8220;message/RFC822&#8221; and SHOULD contain the Content-Type header field parameter &#8220;forwarded=no&#8221; as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>. The wrapper delimits unambigously the Inner Message from the rest of the message.</p>
<h1 id="rfc.section.4.1.4">
<a href="#rfc.section.4.1.4">4.1.4.</a> <a href="#outer-msg-hf" id="outer-msg-hf">Outer Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.4.p.1">To maximize Privacy, it is strongly RECOMMENDED to follow the principle of Data Minimization (cf. <a href="#privacy" class="xref">Section 2.1</a>).</p>
<p id="rfc.section.4.1.4.p.2">However, the Outer Message Header Section SHOULD contain the Essential Header Fields and, in addition, MUST contain the Header Fields of the MIME Header Section part to describe the encryption or signature as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<p id="rfc.section.4.1.4.p.3">The following Header Fields are defined as the Essential Header Fields:</p>
<p></p>
<ul>
<li>From</li>
<li>To (if present in the OrigM)</li>
<li>Cc (if present in the OrigM)</li>
<li>Bcc (if present in the OrigM, see also <a href="#inner-msg-hf" class="xref">Section 4.1.2</a> and <a href="#bcc-handling" class="xref">Appendix A.1</a>)</li>
<li>Date</li>
<li>Message-ID</li>
<li>Subject</li>
</ul>
<p id="rfc.section.4.1.4.p.5">Some of these Header Fields are needed by the Transport (e.g. to determine the destination). Furthermore, not including certain Header Fields may trigger spam detection to flag the message as spam and/or lead to user experience (UX) issues.</p>
<p id="rfc.section.4.1.4.p.6">For further Data Minimization the value of the Subject Header Field SHOULD be obfuscated. In addition, the value of other Essential Header Fields MAY be obfuscated. Further Header Fields MAY be obfuscated, though simply not adding those to the Outer Message Header SHOULD be prefered over obfuscation. Header Field obfuscation is further specified in <a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>. Header Fields not obfuscated SHOULD contain the same values as in the Original Message.</p>
<p id="rfc.section.4.1.4.p.7">The MIME Header Section part is the collection of MIME Header Fields describing the following MIME structure as defined in <a href="#RFC2045" class="xref">[RFC2045]</a>. A MIME Header Section part typically includes the following Header Fields:</p>
<p></p>
<ul>
<li>MIME-Version</li>
<li>Content-Type</li>
<li>Content-Transfer-Encoding</li>
<li>Content-Disposition</li>
</ul>
<p id="rfc.section.4.1.4.p.9">The following example shows the MIME Header Section part of an S&#8288;/&#8288;MIME signed message (using application/pkcs7-mime with SignedData):</p>
<pre>
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
</pre>
<p id="rfc.section.4.1.4.p.10">Depending on the scenario, further Header Fields MAY be exposed in the Outer Message Header Section, which is NOT RECOMMENDED unless justified. Such Header Fields may include e.g.:</p>
<p></p>
<ul>
<li>References</li>
<li>Reply-To</li>
<li>In-Reply-To</li>
</ul>
<h1 id="rfc.section.4.1.4.1">
<a href="#rfc.section.4.1.4.1">4.1.4.1.</a> <a href="#obfuscation-outer-HF" id="obfuscation-outer-HF">Obfuscation of Outer Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.4.1.p.1">If the values of the following Outer Message Header Fields are obfuscated, those SHOULD assume the following values:</p>
<pre>
* Subject: ...
* Message-ID: &lt;new randomly generated Message-ID&gt;
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
</pre>
<p id="rfc.section.4.1.4.1.p.2">[[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the same week. ]]</p>
<p id="rfc.section.4.1.4.1.p.3">In certain implementations also the From, To, and/or Cc Header Field MAY be obfucated. Those may be replaced by e.g.</p>
<p></p>
<ul><li>To: Obfuscated <a href="mailto:anonymous@anonymous.invalid">anonymous@anonymous.invalid</a>
</li></ul>
<p id="rfc.section.4.1.4.1.p.5">Such implementations need to ensure that the Transport has access to these Header Fields in clear text and is capable of processing those.</p>
<p id="rfc.section.4.1.4.1.p.6">A use case for obfuscation of all Outer Message Header Fields is mixnet netwerks, i.e. &#8220;onion routing&#8221; for email (e.g.<a href="#pEp.mixnet" class="xref">[pEp.mixnet]</a>).</p>
<p id="rfc.section.4.1.4.1.p.7">Note: It is for further study to what extent Header Field obfuscation (adversely) impacts spam filtering.</p>
<h1 id="rfc.section.4.1.5">
<a href="#rfc.section.4.1.5">4.1.5.</a> <a href="#rufm-hf" id="rufm-hf">Receiving User Facing Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.5.p.1">The Receiving User Facing Message is constructed as follows:</p>
<p></p>
<ul>
<li>The Header Section of the Receiving User Facing Message MUST consist of the Outer Message Header Fields that are not contained in the Inner Message Header Section, and the Inner Message Header Fields (i.e. the Inner Message Header Field MUST always take precedence).</li>
<li>The Body of the Receiving User Facing Message Body MUST be the same as the Inner Message Body.</li>
</ul>
<p id="rfc.section.4.1.5.p.3">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<h1 id="rfc.section.4.1.6">
<a href="#rfc.section.4.1.6">4.1.6.</a> <a href="#header-field-flow" id="header-field-flow">Header Field Flow</a>
</h1>
<p id="rfc.section.4.1.6.p.1">The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:</p>
<pre>
OrigM InnerM Outer(S) OuterM(R) RUFM
&lt;Trace-HF&gt; &gt; &lt;Trace-HF&gt;
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc* &gt; Bcc
Date (OrigM) = Date
Message-ID (OrigM)= Message-ID
Subject (new) = Subject
&lt;MIME-HSp&gt; (new) = &lt;MIME-HSp&gt;
PROTECTED: PROTECTED:
&lt;Wrapper&gt; (new) = &lt;Wrapper&gt;
From &gt; From &gt; From = From &gt; From
To &gt; To &gt; To = To &gt; To
Cc* &gt; Cc &gt; Cc = Cc &gt; Cc
Bcc*
Date &gt; Date &gt; Date = Date &gt; Date
Message-ID &gt; Message-ID &gt; Message-ID = Message-ID &gt; Message-ID
Subject &gt; Subject &gt; Subject = Subject &gt; Subject
&lt;More HF&gt; &gt; &lt;More HF&gt; &gt; &lt;More HF&gt; = &lt;More HF&gt; &gt; &lt;More-HF&gt;
&lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; = &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt;
&lt;Body&gt; &gt; &lt;Body&gt; &gt; &lt;Body&gt; = &lt;Body&gt; &gt; &lt;Body&gt;
&lt;Signature&gt;* (new)= &lt;Signature&gt;
</pre>
<p id="rfc.section.4.1.6.p.2">Legend:</p>
<p></p>
<ul>
<li>OuterM(S): Outer Message (OuterM) at sending side (before processing by Transport)</li>
<li>OuterM(R): Outer Message at receiving side (as received by Transport)</li>
<li>InnerM: Inner Message (that protection is applied to)</li>
<li>RUFM: Receiving User Facing Message</li>
<li>More-HF: Additional Header Fields (HF) in the Original Message (OrigM)</li>
<li>Wrapper: MIME Header Section; with media type (message/RFC822) to unambigously delimit the inner message from the rest of the message.</li>
<li>MIME-HSp: MIME Header Section part to describe the encryption or signature as per <a href="#RFC8551" class="xref">[RFC8551]</a>
</li>
<li>Trace-HF: Header Fields added in Transit (between sending and receiving side) as per <a href="#RFC5322" class="xref">[RFC5322]</a>
</li>
<li>&gt;: taken over / copied from last column</li>
<li>=: propagates unchanged, unless something unusual (e.g. attack) happens</li>
<li>*: HF that is often not present (also further HFs, e.g. To, may not be present). If a HF is not present, naturally it can neither be taken over nor propagated.</li>
<li>(new) / (OrigM): HF or MIME-HSp is generated depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
</ul>
<h1 id="rfc.section.4.1.7">
<a href="#rfc.section.4.1.7">4.1.7.</a> <a href="#sending-side-message-processing" id="sending-side-message-processing">Sending Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.7.p.1">For a protected message the following steps are applied before a message is handed over to the Transport:</p>
<h1 id="rfc.section.4.1.7.1">
<a href="#rfc.section.4.1.7.1">4.1.7.1.</a> <a href="#sending-side-step-1" id="sending-side-step-1">Step 1: Decide on Protection Level and Information Disclosure</a>
</h1>
<p id="rfc.section.4.1.7.1.p.1">The entity applying protection to a message must decide:</p>
<p></p>
<ul>
<li>Which Protection Level (signature and/or encryption) is applied to the message? This depends on user request and/or local policy as well as availability of cryptographic keys.</li>
<li>Which Header Fields of the Orignial Message shall be part of the Outer Message Header Section? This typically depends on local policy. By default the Essential Header Fields are part of the Outer Message Header Section; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.4</a>.</li>
<li>Which of these Header Fields are to be obfuscated? This depends on local policy and/or specific Privacy requirements of the user. By default only the Subject Header Field is obfuscated; cf. <a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>.</li>
</ul>
<h1 id="rfc.section.4.1.7.2">
<a href="#rfc.section.4.1.7.2">4.1.7.2.</a> <a href="#sending-side-step-2" id="sending-side-step-2">Step 2: Compose the Outer Message Header Section</a>
</h1>
<p id="rfc.section.4.1.7.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>, compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.)</p>
<p id="rfc.section.4.1.7.2.p.2">Outer Header Fields that are not obfuscated should contain the same values as in the Original Message (except for MIME Header Section part, which depends on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>).</p>
<h1 id="rfc.section.4.1.7.3">
<a href="#rfc.section.4.1.7.3">4.1.7.3.</a> <a href="#sending-side-step-3" id="sending-side-step-3">Step 3: Apply Protection to the Original Message</a>
</h1>
<p id="rfc.section.4.1.7.3.p.1">Depending on the Protection Level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a> apply signature and/or encryption to the Original Message including the wrapper (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and set the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.7.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.7.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.8">
<a href="#rfc.section.4.1.8">4.1.8.</a> <a href="#receiving-side-message-processing" id="receiving-side-message-processing">Receiving Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.8.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.8.1">
<a href="#rfc.section.4.1.8.1">4.1.8.1.</a> <a href="#receiving-side-step-1" id="receiving-side-step-1">Step 1: Decrypt message and/or check signature</a>
</h1>
<p id="rfc.section.4.1.8.1.p.1">Depending on the protection level the received message is decrypted and/or its signature is checked as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<h1 id="rfc.section.4.1.8.2">
<a href="#rfc.section.4.1.8.2">4.1.8.2.</a> <a href="#receiving-side-step-2" id="receiving-side-step-2">Step 2: Construct the Receiving User Facing Message</a>
</h1>
<p id="rfc.section.4.1.8.2.p.1">The Receiving User Facing Message is constructed according to <a href="#rufm-hf" class="xref">Section 4.1.5</a>.</p>
<p id="rfc.section.4.1.8.2.p.2">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.8.2.p.3">Note: It is for further study whether and, if yes, how the Outer Message Header Section (as received from the Transport) is preserved for the user.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#backward-compatibility-use-case" id="backward-compatibility-use-case">Backward Compatibility Use Case</a>
</h1>
<p><a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> describes a possibility to achieve backward compatibility with existing S&#8288;/&#8288;MIME (and PGP/MIME) implementations unaware of this specification (Legacy Display). It mainly focuses on email clients that do not render emails using header protection (nicely) and may confuse the user. While this has been observed occasionally in PGP/MIME (cf. <a href="#RFC3156" class="xref">[RFC3156]</a>), the extent of this problem with S&#8288;/&#8288;MIME implementations is still unclear. (Note: At this time, none of the samples in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> applies header protection as specified in Section 3.1 of <a href="#RFC8551" class="xref">[RFC8551]</a>, which is wrapping as Media Type &#8220;message/RFC822&#8221;.)</p>
<p id="rfc.section.4.2.p.2">Should serious backward compatibility issues with rendering at the receiver reveal, the Legacy Display format described in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> may serve as a basis to mitigate those (backward compatibility use case).</p>
<p id="rfc.section.4.2.p.3">Another variant of backward compatibility has been implemented by pEp <a href="#I-D.pep-email" class="xref">[I-D.pep-email]</a>, i.e. pEp Email Format 1.0. At this time pEp has implemented this for PGP/MIME (but not yet S&#8288;/&#8288;MIME).</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.5.p.1">[[ TODO ]]</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#privacy-considerations" id="privacy-considerations">Privacy 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="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.7.p.1">This document requests no action from IANA.</p>
<p id="rfc.section.7.p.2">[[ RFC Editor: This section may be removed before publication. ]]</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#acknowledgments" id="acknowledgments">Acknowledgments</a>
</h1>
<p id="rfc.section.8.p.1">The authors would like to thank the following people who have provided helpful comments and suggestions for this document: Claudio Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol, Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. </p>
<h1 id="rfc.references">
<a href="#rfc.references">9.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">9.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.ietf-lamps-header-protection-requirements">[I-D.ietf-lamps-header-protection-requirements]</b></td>
<td class="top">
<a>Melnikov, A.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requirements-01">Problem Statement and Requirements for Header Protection</a>", Internet-Draft draft-ietf-lamps-header-protection-requirements-01, October 2019.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2045">[RFC2045]</b></td>
<td class="top">
<a>Freed, N.</a> and <a>N. Borenstein</a>, "<a href="https://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>", RFC 2045, DOI 10.17487/RFC2045, November 1996.</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="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="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&#8288;/&#8288;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">9.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.autocrypt-lamps-protected-headers">[I-D.autocrypt-lamps-protected-headers]</b></td>
<td class="top">
<a>Einarsson, B.</a>, <a>juga, j.</a> and <a>D. Gillmor</a>, "<a href="https://tools.ietf.org/html/draft-autocrypt-lamps-protected-headers-02">Protected Headers for Cryptographic E-mail</a>", Internet-Draft draft-autocrypt-lamps-protected-headers-02, December 2019.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.melnikov-iana-reg-forwarded">[I-D.melnikov-iana-reg-forwarded]</b></td>
<td class="top">
<a>Melnikov, A.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-melnikov-iana-reg-forwarded-00">IANA Registration of Content-Type Header Field Parameter 'forwarded'</a>", Internet-Draft draft-melnikov-iana-reg-forwarded-00, November 2019.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.pep-email">[I-D.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="pEp.mixnet">[pEp.mixnet]</b></td>
<td class="top">
<a>pEp Foundation</a>, "<a href="https://dev.pep.foundation/Mixnet">Mixnet</a>", June 2020.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3156">[RFC3156]</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="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="RFC6376">[RFC6376]</b></td>
<td class="top"></