forked from pEp.foundation/internet-drafts
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.
1209 lines
60 KiB
HTML
1209 lines
60 KiB
HTML
<!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>Problem Statement and Requirements for Header Protection</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.3" rel="Chapter" title="3 Use Cases">
|
|
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Interactions">
|
|
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Protection Levels">
|
|
<link href="#rfc.section.4" rel="Chapter" title="4 Requirements">
|
|
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 General Requirements">
|
|
<link href="#rfc.section.4.1.1" rel="Chapter" title="4.1.1 Sending Side">
|
|
<link href="#rfc.section.4.1.2" rel="Chapter" title="4.1.2 Receiving Side">
|
|
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection">
|
|
<link href="#rfc.section.4.2.1" rel="Chapter" title="4.2.1 Sending side">
|
|
<link href="#rfc.section.4.2.2" rel="Chapter" title="4.2.2 Receiving side">
|
|
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)">
|
|
<link href="#rfc.section.4.3.1" rel="Chapter" title="4.3.1 Sending Side">
|
|
<link href="#rfc.section.4.3.2" rel="Chapter" title="4.3.2 Receiving Side">
|
|
<link href="#rfc.section.5" rel="Chapter" title="5 Options to Achieve Header Protection">
|
|
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Option 1: Memory Hole">
|
|
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Option 2: Wrapping with message/rfc822 or message/global">
|
|
<link href="#rfc.section.5.2.1" rel="Chapter" title="5.2.1 Content-Type property “forwarded”">
|
|
<link href="#rfc.section.5.2.2" rel="Chapter" title="5.2.2 Handling of S/MIME protected header">
|
|
<link href="#rfc.section.5.2.3" rel="Chapter" title="5.2.3 Mail User Agent Algorithm for deciding which version of a header">
|
|
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Option 3: Progressive Header Disclosure">
|
|
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Design principles">
|
|
<link href="#rfc.section.5.5" rel="Chapter" title="5.5 Candidate Header Fields for Header Protection">
|
|
<link href="#rfc.section.5.6" rel="Chapter" title="5.6 Stub Outside Headers">
|
|
<link href="#rfc.section.5.7" rel="Chapter" title="5.7 More information">
|
|
<link href="#rfc.section.6" rel="Chapter" title="6 Examples">
|
|
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Option 1: Memory Hole">
|
|
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Option 2: Wrapping with message/rfc822 or message/global">
|
|
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Option 3 Progressive Header Disclosure">
|
|
<link href="#rfc.section.7" rel="Chapter" title="7 Security Considerations">
|
|
<link href="#rfc.section.8" rel="Chapter" title="8 Privacy Considerations">
|
|
<link href="#rfc.section.9" rel="Chapter" title="9 IANA Considerations">
|
|
<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 Document Changelog">
|
|
<link href="#rfc.appendix.B" rel="Chapter" title="B Open Issues">
|
|
<link href="#rfc.authors" rel="Chapter">
|
|
|
|
|
|
<meta name="generator" content="xml2rfc version 2.9.6 - https://tools.ietf.org/tools/xml2rfc" />
|
|
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
|
|
|
|
<meta name="dct.creator" content="Melnikov, A., Hoeneisen, B., and D. Gillmor" />
|
|
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-lamps-header-protection-req-00" />
|
|
<meta name="dct.issued" scheme="ISO8601" content="2019-06-24" />
|
|
<meta name="dct.abstract" content="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." />
|
|
<meta name="description" content="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." />
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<table class="header">
|
|
<tbody>
|
|
|
|
<tr>
|
|
<td class="left">Network Working Group</td>
|
|
<td class="right">A. Melnikov</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left">Internet-Draft</td>
|
|
<td class="right">Isode Ltd</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left">Intended status: Informational</td>
|
|
<td class="right">B. Hoeneisen</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left">Expires: December 26, 2019</td>
|
|
<td class="right">Ucom.ch</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left"></td>
|
|
<td class="right">D. Gillmor</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left"></td>
|
|
<td class="right">American Civil Liberties Union</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="left"></td>
|
|
<td class="right">June 24, 2019</td>
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
|
</table>
|
|
|
|
<p class="title">Problem Statement and Requirements for Header Protection<br />
|
|
<span class="filename">draft-ietf-lamps-header-protection-req-00</span></p>
|
|
|
|
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
|
|
<p>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.</p>
|
|
<p>In LAMPS voices have also been expressed, that whatever mechanism will be chosen, it should not be limited to S​/​MIME, but also applicable to PGP/MIME.</p>
|
|
<p>This document describes the problem statement, generic use cases, and requirments. Additionally it drafts possible solutions to address the challenge. Finally some best practices are collected.</p>
|
|
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
|
|
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
|
|
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
|
|
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
|
|
<p>This Internet-Draft will expire on December 26, 2019.</p>
|
|
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
|
|
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
|
|
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
|
|
|
|
|
|
<hr class="noprint" />
|
|
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
|
|
<ul class="toc">
|
|
|
|
<li>1. <a href="#rfc.section.1">Introduction</a>
|
|
</li>
|
|
<ul><li>1.1. <a href="#rfc.section.1.1">Requirements Language</a>
|
|
</li>
|
|
<li>1.2. <a href="#rfc.section.1.2">Terms</a>
|
|
</li>
|
|
</ul><li>2. <a href="#rfc.section.2">Problem Statement</a>
|
|
</li>
|
|
<li>3. <a href="#rfc.section.3">Use Cases</a>
|
|
</li>
|
|
<ul><li>3.1. <a href="#rfc.section.3.1">Interactions</a>
|
|
</li>
|
|
<li>3.2. <a href="#rfc.section.3.2">Protection Levels</a>
|
|
</li>
|
|
</ul><li>4. <a href="#rfc.section.4">Requirements</a>
|
|
</li>
|
|
<ul><li>4.1. <a href="#rfc.section.4.1">General Requirements</a>
|
|
</li>
|
|
<ul><li>4.1.1. <a href="#rfc.section.4.1.1">Sending Side</a>
|
|
</li>
|
|
<li>4.1.2. <a href="#rfc.section.4.1.2">Receiving Side</a>
|
|
</li>
|
|
</ul><li>4.2. <a href="#rfc.section.4.2">Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection</a>
|
|
</li>
|
|
<ul><li>4.2.1. <a href="#rfc.section.4.2.1">Sending side</a>
|
|
</li>
|
|
<li>4.2.2. <a href="#rfc.section.4.2.2">Receiving side</a>
|
|
</li>
|
|
</ul><li>4.3. <a href="#rfc.section.4.3">Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)</a>
|
|
</li>
|
|
<ul><li>4.3.1. <a href="#rfc.section.4.3.1">Sending Side</a>
|
|
</li>
|
|
<li>4.3.2. <a href="#rfc.section.4.3.2">Receiving Side</a>
|
|
</li>
|
|
</ul></ul><li>5. <a href="#rfc.section.5">Options to Achieve Header Protection</a>
|
|
</li>
|
|
<ul><li>5.1. <a href="#rfc.section.5.1">Option 1: Memory Hole</a>
|
|
</li>
|
|
<li>5.2. <a href="#rfc.section.5.2">Option 2: Wrapping with message/rfc822 or message/global</a>
|
|
</li>
|
|
<ul><li>5.2.1. <a href="#rfc.section.5.2.1">Content-Type property “forwarded”</a>
|
|
</li>
|
|
<li>5.2.2. <a href="#rfc.section.5.2.2">Handling of S/MIME protected header</a>
|
|
</li>
|
|
<li>5.2.3. <a href="#rfc.section.5.2.3">Mail User Agent Algorithm for deciding which version of a header</a>
|
|
</li>
|
|
</ul><li>5.3. <a href="#rfc.section.5.3">Option 3: Progressive Header Disclosure</a>
|
|
</li>
|
|
<li>5.4. <a href="#rfc.section.5.4">Design principles</a>
|
|
</li>
|
|
<li>5.5. <a href="#rfc.section.5.5">Candidate Header Fields for Header Protection</a>
|
|
</li>
|
|
<li>5.6. <a href="#rfc.section.5.6">Stub Outside Headers</a>
|
|
</li>
|
|
<li>5.7. <a href="#rfc.section.5.7">More information</a>
|
|
</li>
|
|
</ul><li>6. <a href="#rfc.section.6">Examples</a>
|
|
</li>
|
|
<ul><li>6.1. <a href="#rfc.section.6.1">Option 1: Memory Hole</a>
|
|
</li>
|
|
<li>6.2. <a href="#rfc.section.6.2">Option 2: Wrapping with message/rfc822 or message/global</a>
|
|
</li>
|
|
<li>6.3. <a href="#rfc.section.6.3">Option 3 Progressive Header Disclosure</a>
|
|
</li>
|
|
</ul><li>7. <a href="#rfc.section.7">Security Considerations</a>
|
|
</li>
|
|
<li>8. <a href="#rfc.section.8">Privacy Considerations</a>
|
|
</li>
|
|
<li>9. <a href="#rfc.section.9">IANA Considerations</a>
|
|
</li>
|
|
<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">Document Changelog</a>
|
|
</li>
|
|
<li>Appendix B. <a href="#rfc.appendix.B">Open Issues</a>
|
|
</li>
|
|
<li><a href="#rfc.authors">Authors' Addresses</a>
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
<h1 id="rfc.section.1">
|
|
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
|
|
</h1>
|
|
<p 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 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 headers 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 of all information, which technically can be hidden, 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​/​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 “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.</li></ul>
|
|
<p id="rfc.section.1.p.5">No mechanism for header protection has been standardized for PGP (Pretty Good Privacy) yet.</p>
|
|
<p id="rfc.section.1.p.6">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. At least two variants of header protection are known to be implemented.</p>
|
|
<p id="rfc.section.1.p.7">This document describes the problem statement, generic use cases (<a href="#use-cases" class="xref">Section 3</a>) and requirements for header protection (<a href="#requirements" class="xref">Section 4</a>) Additionally it drafts possible solutions to address the challenge. However, the final solution will be determined by the IETF LAMPS WG. Finally, some best practices are collected.</p>
|
|
<p id="rfc.section.1.p.8">[…]</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 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” 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>Header Field:: cf. <a href="#RFC5322" class="xref">[RFC5322]</a>
|
|
</li>
|
|
<li>Header Section: cf. <a href="#RFC5322" class="xref">[RFC5322]</a>
|
|
</li>
|
|
<li>Signed-only message: a multipart/signed or application/pkcs7-mime containing SignedData message which doesn’t contain any encrypted layer. I.e. this is a message which is not encrypted and not encrypted + signed.</li>
|
|
</ul>
|
|
<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="#problem-statement" id="problem-statement">Problem Statement</a>
|
|
</h1>
|
|
<p id="rfc.section.2.p.1">The LAMPS charter contains the folllowing Work Item:</p>
|
|
<p></p>
|
|
|
|
<ul class="empty"><li>Update the specification for the cryptographic protection of email headers – both for signatures and encryption – 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">[…]</p>
|
|
<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, we show the generic use cases that need to be addressed independently of whether S​/​MIME, PGP/MIME or any other technology is used for which Header Protection (HP) is to be applied to.</p>
|
|
<h1 id="rfc.section.3.1">
|
|
<a href="#rfc.section.3.1">3.1.</a> <a href="#interactions" id="interactions">Interactions</a>
|
|
</h1>
|
|
<p id="rfc.section.3.1.p.1">The main interaction case for Header Protection (HP) is:</p>
|
|
<pre>
|
|
1) Both peers (sending and receiving side) fully support HP
|
|
|
|
</pre>
|
|
<p id="rfc.section.3.1.p.2">For backward compatibility of legacy clients – unaware of any HP – the following intermediate interactions need to be considered as well:</p>
|
|
<pre>
|
|
2) The sending side fully supports HP, while the receiving side does
|
|
not support any HP
|
|
|
|
3) The sending side does not support any HP, while the receiving
|
|
side fully supports HP (trivial case)
|
|
|
|
4) Neither the sending side nor the receiving side supports any HP
|
|
(trivial case)
|
|
|
|
</pre>
|
|
<p id="rfc.section.3.1.p.3">The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S​/​MIME since version 3.1 (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>), in the following designated as legacy HP:</p>
|
|
<pre>
|
|
5) The sending side fully supports HP, while the receiving side
|
|
supports legacy HP only
|
|
|
|
6) The sending side supports legacy HP only, while the receiving side
|
|
fully supports HP
|
|
|
|
7) Both peers (sending and receiving side) support legacy HP only
|
|
|
|
8) The sending side supports legacy HP only, while the receiving side
|
|
does not support any HP
|
|
|
|
9) The sending side does not support any HP, while the receiving side
|
|
supports legacy HP only (trivial case)
|
|
|
|
</pre>
|
|
<p id="rfc.section.3.1.p.4">Note: It is to be decided whether to ensure legacy HP systems do not conflict with any new solution for HP at all or whether (and to which degree) backward compatibility to legacy HP systems shall be maintained.</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>
|
|
<p id="rfc.section.3.2.p.3">b) signature only</p>
|
|
<p id="rfc.section.3.2.p.4">c) encryption only [[ TODO: verify whether relevant ]]</p>
|
|
<h1 id="rfc.section.4">
|
|
<a href="#rfc.section.4">4.</a> <a href="#requirements" id="requirements">Requirements</a>
|
|
</h1>
|
|
<p id="rfc.section.4.p.1">In the following a list of requirements that need to be addressed independently of whether S​/​MIME, PGP/MIME or any other technology is used to apply HP to.</p>
|
|
<h1 id="rfc.section.4.1">
|
|
<a href="#rfc.section.4.1">4.1.</a> <a href="#general-requirements" id="general-requirements">General Requirements</a>
|
|
</h1>
|
|
<p id="rfc.section.4.1.p.1">This subsection is listing the requirements to address use case 1) (cf. <a href="#interactions" class="xref">Section 3.1</a>).</p>
|
|
<pre>
|
|
G1: Define the format for HP for all protection levels. This includes
|
|
MIME structure, Content-Type (including charset and name),
|
|
Content-Disposition (including filename), and
|
|
Content-Transfer-Encoding.
|
|
|
|
G2: Define how a public key should be included.
|
|
|
|
G3: To foster wide implementation of the new solution, it shall be
|
|
easily implementable. Unless needed for maximizing protection and
|
|
privacy, existing implementations shall not require substantial
|
|
changes in the existing code base. In particular also MIME
|
|
libraries widely used shall not need to be changed to comply with
|
|
the new mechanism for HP.
|
|
|
|
G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
|
|
particular downgrade attacks, are mitigated as good as possible.
|
|
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.1.1">
|
|
<a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#sending-side" id="sending-side">Sending Side</a>
|
|
</h1>
|
|
<pre>
|
|
GS1: Determine which Header Fields (HFs) should or must be protected
|
|
at least for signed only email.
|
|
|
|
GS2: Determine which HFs should or must be sent in clear of an
|
|
encrypted email.
|
|
|
|
GS3: Determine which HF should not or must not be included in the
|
|
visible header (for transport) of an encrypted email, with the
|
|
default being that whatever is not needed from GS2 is not put
|
|
into the unencrypted transport headers, thus fulfilling data
|
|
minimization requirements (including data spareness and hiding
|
|
of all information that technically can be hidden).
|
|
|
|
GS4: Determine which HF to not to include to any HP part (e.g. Bcc).
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.1.2">
|
|
<a href="#rfc.section.4.1.2">4.1.2.</a> <a href="#receiving-side" id="receiving-side">Receiving Side</a>
|
|
</h1>
|
|
<pre>
|
|
GR1: Determine how HF should be displayed to the user in case of
|
|
conflicting information between the protected and unprotected
|
|
headers.
|
|
|
|
GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
|
|
particular downgrade attacks, can be detected.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.2">
|
|
<a href="#rfc.section.4.2">4.2.</a> <a href="#additional-requirements-for-backward-compatibility-with-legacy-clients-unaware-of-header-protection" id="additional-requirements-for-backward-compatibility-with-legacy-clients-unaware-of-header-protection">Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection</a>
|
|
</h1>
|
|
<p id="rfc.section.4.2.p.1">This sub-section addresses the use cases 2) - 4) (cf. <a href="#interactions" class="xref">Section 3.1</a>)</p>
|
|
<pre>
|
|
B1: Depending on the solution, define a means to distinguish between
|
|
forwarded messages and encapsulated messages using new HP
|
|
mechanism.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.2.1">
|
|
<a href="#rfc.section.4.2.1">4.2.1.</a> <a href="#sending-side-1" id="sending-side-1">Sending side</a>
|
|
</h1>
|
|
<pre>
|
|
BS1: Define how full HP support can be indicated to outgoing
|
|
messages.
|
|
|
|
BS2: Define how full HP support of the receiver can be detected or
|
|
guessed.
|
|
|
|
BS3: Ensure a HP unaware receiving side easily can display the
|
|
"Subject" HF to the user.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.2.2">
|
|
<a href="#rfc.section.4.2.2">4.2.2.</a> <a href="#receiving-side-1" id="receiving-side-1">Receiving side</a>
|
|
</h1>
|
|
<pre>
|
|
BR1: Define how full HP support can be detected in incoming messages.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.3">
|
|
<a href="#rfc.section.4.3">4.3.</a> <a href="#additional-requirements-for-backward-compatibility-with-legacy-header-protection-systems-if-supported" id="additional-requirements-for-backward-compatibility-with-legacy-header-protection-systems-if-supported">Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)</a>
|
|
</h1>
|
|
<p id="rfc.section.4.3.p.1">This sub-section addresses the use cases 5) - 9) (cf. <a href="#interactions" class="xref">Section 3.1</a>).</p>
|
|
<pre>
|
|
LS1: Depending on the solution, define a means to distinguish between
|
|
forwarded messages, legacy encapsulated messages, and
|
|
encapsulated messages using new HP mechanism.
|
|
|
|
LS2: The solution should be backward compatible to existing solutions
|
|
and aim to minimize the implementation effort to include support
|
|
for existing solutions.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.3.1">
|
|
<a href="#rfc.section.4.3.1">4.3.1.</a> <a href="#sending-side-2" id="sending-side-2">Sending Side</a>
|
|
</h1>
|
|
<pre>
|
|
LSS1: Determine how legacy HP support can be indicated to outgoing
|
|
messages.
|
|
|
|
LSS2: Determine how legacy HP support of the receiver can be detected
|
|
or guessed.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.4.3.2">
|
|
<a href="#rfc.section.4.3.2">4.3.2.</a> <a href="#receiving-side-2" id="receiving-side-2">Receiving Side</a>
|
|
</h1>
|
|
<pre>
|
|
LSR1: Determine how legacy HP support can be detected in incoming
|
|
messages.
|
|
|
|
</pre>
|
|
<h1 id="rfc.section.5">
|
|
<a href="#rfc.section.5">5.</a> <a href="#options-to-achieve-header-protection" id="options-to-achieve-header-protection">Options to Achieve Header Protection</a>
|
|
</h1>
|
|
<p id="rfc.section.5.p.1">In the following a set of Options to achieve Email Header Protection. It is expected that the IETF LAMPS WG chooses an option to update <a href="#RFC8551" class="xref">[RFC8551]</a> wrt. Header Protection.</p>
|
|
<h1 id="rfc.section.5.1">
|
|
<a href="#rfc.section.5.1">5.1.</a> <a href="#memory-hole" id="memory-hole">Option 1: Memory Hole</a>
|
|
</h1>
|
|
<p id="rfc.section.5.1.p.1">Memory Hole approach works by copying the normal message header fields into the MIME header section of the top level protected body part. Since the MIME body part header section is itself covered by the protection mechanisms (signing and/or encryption) it shares the protections of the message body.</p>
|
|
<p id="rfc.section.5.1.p.2">[[ TODO: [DKG] add more information on memory hole]]</p>
|
|
<h1 id="rfc.section.5.2">
|
|
<a href="#rfc.section.5.2">5.2.</a> <a href="#rfc822-wrapping" id="rfc822-wrapping">Option 2: Wrapping with message/rfc822 or message/global</a>
|
|
</h1>
|
|
<p id="rfc.section.5.2.p.1">Wrapping with message/rfc822 (or message/global) works by copying the normal message header fields into the MIME header section of the top level protect body part</p>
|
|
<p id="rfc.section.5.2.p.2">[[ HB: Not sure this is well expressed: In option 2 the whole message is copied into the MIME body part as message/rfc822 element. ]]</p>
|
|
<p id="rfc.section.5.2.p.3">and then prepending them with “Content-Type: message/rfc822; forwarded=no\r\n” or “Content-Type: message/global; forwarded=no\r\n”, where \r\n is US-ASCII CR followed by US-ASCII LF. Since the MIME body part header section is itself covered by the protection mechanisms (signing and/or encryption) it shares the protections of the message body.</p>
|
|
<h1 id="rfc.section.5.2.1">
|
|
<a href="#rfc.section.5.2.1">5.2.1.</a> <a href="#content-type-property-forwarded" id="content-type-property-forwarded">Content-Type property “forwarded”</a>
|
|
</h1>
|
|
<p id="rfc.section.5.2.1.p.1">This section outlines how the new “forwarded” Content-Type header field parameter could be defined (probabely in a separate document) and how header section wrapping works:</p>
|
|
<p id="rfc.section.5.2.1.p.2">This document defines a new Content-Type header field parameter <a href="#RFC2045" class="xref">[RFC2045]</a> with name “forwarded”. The parameter value is case- insensitive and can be either “yes” or “no”. (The default value being “yes”). The parameter is only meaningful with media type “message/rfc822” and “message/global” <a href="#RFC6532" class="xref">[RFC6532]</a> when used within S​/​MIME signed or encrypted body parts. The value “yes” means that the message nested inside “message/rfc822” (“message/global”) is a forwarded message and not a construct created solely to protect the inner header section.</p>
|
|
<p id="rfc.section.5.2.1.p.3">Instructions in <a href="#RFC8551" class="xref">[RFC8551]</a> describing how to protect the Email message header section <a href="#RFC5322" class="xref">[RFC5322]</a>, by wrapping the message inside a message/ rfc822 container <a href="#RFC2045" class="xref">[RFC2045]</a> are thus updated to read:</p>
|
|
<p></p>
|
|
|
|
<ul class="empty"><li>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 section along with the unprotected “outer” header section.</li></ul>
|
|
<p></p>
|
|
|
|
<ul class="empty"><li>When an S​/​MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822 or message/global without the “forwarded” parameter or with the “forwarded” parameter set to “no”, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header section merging issues as previously discussed.</li></ul>
|
|
<h1 id="rfc.section.5.2.2">
|
|
<a href="#rfc.section.5.2.2">5.2.2.</a> <a href="#handling-of-smime-protected-header" id="handling-of-smime-protected-header">Handling of S/MIME protected header</a>
|
|
</h1>
|
|
<p id="rfc.section.5.2.2.p.1">[[This section needs more work. Don’t treat anything in it as unchangeable.]]</p>
|
|
<p id="rfc.section.5.2.2.p.2">For a signed-only message, it is RECOMMENDED that all “outer” header fields are copied into the “inner” protected body part. This would mean that all header fields are signed. In this case, the “outer” header fields simply match the protected header fields. And in the case that the “outer” header fields differ, they can simply be replaced with their protected versions when displayed to the user.</p>
|
|
<p id="rfc.section.5.2.2.p.3">When generating encrypted or encrypted+signed S​/​MIME messages which protect header fields:</p>
|
|
<p></p>
|
|
|
|
<ol>
|
|
<li>If a header field is being encrypted because it is sensitive, its true value MUST NOT be included in the outer header. If the header field is mandatory according to <a href="#RFC5322" class="xref">[RFC5322]</a>, a stub value (or a value indicating that the outer value is not to be used) is to be included in the outer header section.</li>
|
|
<li>The outer header section SHOULD be minimal in order to avoid disclosure of confidential information. It is recommended that the outer header section only contains “Date” (set to the same value as in the inner header field, or, if the Date value is also sensitive, to Monday 9am of the same week), possibly “Subject” and “To”/”Bcc” header fields. In particular, Keywords, In-Reply- To and References header fields SHOULD NOT be included in the outer header; “To” and “Cc” header fields should be omitted and replaced with “Bcc: undisclosed-recipients;”. <br><br> But note that having key header fields duplicated in the outer header is convenient for many message stores (e.g. IMAP) and clients that can’t decode S​/​MIME encrypted messages. In particular, Subject/To/Cc/Bcc/Date header field values are returned in IMAP ENVELOPE FETCH data item <a href="#RFC3501" class="xref">[RFC3501]</a>, which is frequently used by IMAP clients in order to avoid parsing message header.</li>
|
|
<li>The “Subject” header field value of the outer header section SHOULD either be identical to the inner “Subject” header field value, or contain a clear indication that the outer value is not to be used for display (the inner header field value would contain the true value).</li>
|
|
</ol>
|
|
<p id="rfc.section.5.2.2.p.5">Note that recommendations listed above typically only apply to non MIME header fields (header fields with names not starting with “Content-“ prefix), but there are exception, e.g. Content-Language.</p>
|
|
<p id="rfc.section.5.2.2.p.6">Note that the above recommendations can also negatively affect antispam processing.</p>
|
|
<p id="rfc.section.5.2.2.p.7">When displaying S​/​MIME messages which protect header fields (whether they are signed-only, encrypted or encrypted+signed):</p>
|
|
<p></p>
|
|
|
|
<ol><li>The outer headers might be tampered with, so a receiving client SHOULD ignore them, unless they are protected in some other way(<em>). If a header field is present in the inner header, only the inner header field value MUST be displayed (and the corresponding outer value must be ignored). If a particular header field is only present in the outer header, it MAY be ignored (not displayed) or it MAY be displayed with a clear indicator that it is not trustworthy(</em>). <br><br> (*) - this only applies if the header field is not protected is some other way, for example with a DKIM signature that validates and is trusted.</li></ol>
|
|
<h1 id="rfc.section.5.2.3">
|
|
<a href="#rfc.section.5.2.3">5.2.3.</a> <a href="#mail-user-agent-algorithm-for-deciding-which-version-of-a-header" id="mail-user-agent-algorithm-for-deciding-which-version-of-a-header">Mail User Agent Algorithm for deciding which version of a header</a>
|
|
</h1>
|
|
<p id="rfc.section.5.2.3.p.1">field to display</p>
|
|
<p id="rfc.section.5.2.3.p.2">[[TBD: describe how to recurse to find the innermost protected root body part, extract header fields from it and propogate them to the top level. This should also work for triple-wrapped messages.]]</p>
|
|
<h1 id="rfc.section.5.3">
|
|
<a href="#rfc.section.5.3">5.3.</a> <a href="#progressive-header-disclosure" id="progressive-header-disclosure">Option 3: Progressive Header Disclosure</a>
|
|
</h1>
|
|
<p id="rfc.section.5.3.p.1">This option is similar to Option 2 (cf. <a href="#rfc822-wrapping" class="xref">Section 5.2</a>). It also makes use the Content-Type property “forwarded” (cf. <a href="#content-type-property-forwarded" class="xref">Section 5.2.1</a>).</p>
|
|
<h1 id="rfc.section.5.4">
|
|
<a href="#rfc.section.5.4">5.4.</a> <a href="#design-principles" id="design-principles">Design principles</a>
|
|
</h1>
|
|
<p id="rfc.section.5.4.p.1">pretty Easy privacy (pEp) <a href="#I-D.birk-pep" class="xref">[I-D.birk-pep]</a> 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 attaining to good security practice while still retaining backward compatibility for implementations widespread.</p>
|
|
<p id="rfc.section.5.4.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.5.4.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.5.4.p.4">The pEp message format is equivalent to the S​/​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​/​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.5.4.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​/​MIME is next.</p>
|
|
<p id="rfc.section.5.4.p.6">pEp’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.5.4.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.5.4.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>
|
|
<p id="rfc.section.5.4.p.9">pEp has also implemented the above (in <a href="#content-type-property-forwarded" class="xref">Section 5.2.1</a>) described Content-Type property “forwarded” to distinguish between encapsulated and forwarded emails.</p>
|
|
<h1 id="rfc.section.5.5">
|
|
<a href="#rfc.section.5.5">5.5.</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.5.5.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 “Bcc” MUST NOT be added to the protected headers.</li></ul>
|
|
<h1 id="rfc.section.5.6">
|
|
<a href="#rfc.section.5.6">5.6.</a> <a href="#stub-outside-headers" id="stub-outside-headers">Stub Outside Headers</a>
|
|
</h1>
|
|
<p id="rfc.section.5.6.p.1">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.</p>
|
|
<p id="rfc.section.5.6.p.2">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 <a href="#RFC5322" class="xref">[RFC5322]</a>. They SHOULD be conserved for reliability.</p>
|
|
<p id="rfc.section.5.6.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.5.6.p.5">The entries with an asterisk mark (*) should only be set if also present in the original message.</p>
|
|
<h1 id="rfc.section.5.7">
|
|
<a href="#rfc.section.5.7">5.7.</a> <a href="#more-information" id="more-information">More information</a>
|
|
</h1>
|
|
<p id="rfc.section.5.7.p.1">More information on progressive header disclosure can be found in <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a> and <a href="#I-D.luck-lamps-pep-header-protection" class="xref">[I-D.luck-lamps-pep-header-protection]</a>. The latter is a predecessor of this document.</p>
|
|
<h1 id="rfc.section.6">
|
|
<a href="#rfc.section.6">6.</a> <a href="#examples" id="examples">Examples</a>
|
|
</h1>
|
|
<p id="rfc.section.6.p.1">Examples in subsequent sections assume that an email client is trying to protect (sign) the following initial message:</p>
|
|
<pre>
|
|
Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
MIME-Version: 1.0
|
|
MMHS-Primary-Precedence: 3
|
|
Subject: Meeting at my place
|
|
To: somebody@example.net
|
|
X-Mailer: Isode Harrier Web Server
|
|
Content-Type: text/plain; charset=us-ascii
|
|
|
|
This is an important message that I don't want to be modified.
|
|
|
|
Without message header protection the corresponding signed message
|
|
might look like this. (Lines prepended by "O: " are the outer
|
|
header.)
|
|
|
|
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
O: Subject: Meeting at my place
|
|
O: From: "Alexey Melnikov" <alexey.melnikov@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
|
|
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>
|
|
<h1 id="rfc.section.6.1">
|
|
<a href="#rfc.section.6.1">6.1.</a> <a href="#memory-hole-example" id="memory-hole-example">Option 1: Memory Hole</a>
|
|
</h1>
|
|
<p id="rfc.section.6.1.p.1">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 “O: “ are the outer header section. Lines prepended by “I: “ are the inner header section.</p>
|
|
<pre>
|
|
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
O: Subject: Meeting at my place
|
|
O: From: "Alexey Melnikov" <alexey.melnikov@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
|
|
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
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>
|
|
<h1 id="rfc.section.6.2">
|
|
<a href="#rfc.section.6.2">6.2.</a> <a href="#rfc822-wrapping-example" id="rfc822-wrapping-example">Option 2: Wrapping with message/rfc822 or message/global</a>
|
|
</h1>
|
|
<p id="rfc.section.6.2.p.1">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 “O: “ are the outer header section. Lines prepended by “I: “ are the inner header section. Lines prepended by “W: “ are the wrapper.</p>
|
|
<pre>
|
|
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
|
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
O: Subject: Meeting at my place
|
|
O: From: "Alexey Melnikov" <alexey.melnikov@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" <alexey.melnikov@example.net>
|
|
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
|
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>
|
|
<h1 id="rfc.section.6.3">
|
|
<a href="#rfc.section.6.3">6.3.</a> <a href="#progressive-header-disclosure-example" id="progressive-header-disclosure-example">Option 3 Progressive Header Disclosure</a>
|
|
</h1>
|
|
<p id="rfc.section.6.3.p.1">This looks similar as in option 2. Specific examples can be found in <a href="#I-D.luck-lamps-pep-header-protection" class="xref">[I-D.luck-lamps-pep-header-protection]</a>.</p>
|
|
<h1 id="rfc.section.7">
|
|
<a href="#rfc.section.7">7.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
|
|
</h1>
|
|
<p id="rfc.section.7.p.1">This document talks about UI considerations, including security considerations, when processing messages protecting header fields. One of the goals of this document is to specify UI for displaying such messages which is less confusing/misleading and thus more secure.</p>
|
|
<p id="rfc.section.7.p.2">The document is not defining new protocol, so it doesn’t create any new security concerns not already covered by S​/​MIME <a href="#RFC8551" class="xref">[RFC8551]</a>, MIME <a href="#RFC2045" class="xref">[RFC2045]</a> and Email <a href="#RFC5322" class="xref">[RFC5322]</a> in general.</p>
|
|
<h1 id="rfc.section.8">
|
|
<a href="#rfc.section.8">8.</a> <a href="#privacy-considerations" id="privacy-considerations">Privacy Considerations</a>
|
|
</h1>
|
|
<p id="rfc.section.8.p.1">[[ TODO ]]</p>
|
|
<h1 id="rfc.section.9">
|
|
<a href="#rfc.section.9">9.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
|
|
</h1>
|
|
<p id="rfc.section.9.p.1">This document requests no action from IANA.</p>
|
|
<p id="rfc.section.9.p.2">[[ RFC Editor: This section may be removed before publication. ]]</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">Special thanks go to Krista Bennett and Volker Birk for valuable input to this draft and Hernani Marques for reviewing.</p>
|
|
<p id="rfc.section.10.p.2">[[ TODO [AM]: Do we need to mention: Wei Chuang, Steve Kille, David Wilson and Robert Williams (copied from Acknowledgements section of <a href="#I-D.melnikov-lamps-header-protection" class="xref">[I-D.melnikov-lamps-header-protection]</a> ]]</p>
|
|
<p id="rfc.section.10.p.3">Special thanks to Claudio Luck who authored a predecessor of this document. Essential parts of his work have been merged into this one.</p>
|
|
<p id="rfc.section.10.p.4">David Wilson came up with the idea of defining a new Content-Type header field parameter to distinguish forwarded messages from inner header field protection constructs.</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="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="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​/​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="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.luck-lamps-pep-header-protection">[I-D.luck-lamps-pep-header-protection]</b></td>
|
|
<td class="top">
|
|
<a>Luck, C.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-luck-lamps-pep-header-protection-02">pretty Easy privacy (pEp): Header Protection</a>", Internet-Draft draft-luck-lamps-pep-header-protection-02, 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​/​MIME</a>", Internet-Draft draft-melnikov-lamps-header-protection-00, October 2018.</td>
|
|
</tr>
|
|
<tr>
|
|
<td class="reference"><b id="RFC3501">[RFC3501]</b></td>
|
|
<td class="top">
|
|
<a>Crispin, M.</a>, "<a href="https://tools.ietf.org/html/rfc3501">INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</a>", RFC 3501, DOI 10.17487/RFC3501, March 2003.</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">
|
|
<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="RFC6532">[RFC6532]</b></td>
|
|
<td class="top">
|
|
<a>Yang, A.</a>, <a>Steele, S.</a> and <a>N. Freed</a>, "<a href="https://tools.ietf.org/html/rfc6532">Internationalized Email Headers</a>", RFC 6532, DOI 10.17487/RFC6532, February 2012.</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>
|
|
</tbody></table>
|
|
<h1 id="rfc.appendix.A">
|
|
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
|
|
</h1>
|
|
<p id="rfc.section.A.p.1">[[ RFC Editor: This section is to be removed before publication ]]</p>
|
|
<p></p>
|
|
|
|
<ul><li>draft-ietf-lamps-header-protection-req-00 <ul><li>Initial version</li></ul>
|
|
</li></ul>
|
|
<h1 id="rfc.appendix.B">
|
|
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#open-issues" id="open-issues">Open Issues</a>
|
|
</h1>
|
|
<p id="rfc.section.B.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication. ]]</p>
|
|
<p></p>
|
|
|
|
<ul>
|
|
<li>filename of the document <ul><li>does draft-ietf-lamps-header-protection-req work to keep draft-ietf-lamps-header-protection free for the specification? Or do we expect only one document at the end of the day?</li></ul>
|
|
</li>
|
|
<li>Signed-only protection needs further study <ul><li>pEp only does header protection by applying both signing and encryption. Technically it is also possible to sign, but not encrypt the protected messages. This needs further study.</li></ul>
|
|
</li>
|
|
</ul>
|
|
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
|
|
<div class="avoidbreak">
|
|
<address class="vcard">
|
|
<span class="vcardline">
|
|
<span class="fn">Alexey Melnikov</span>
|
|
<span class="n hidden">
|
|
<span class="family-name">Melnikov</span>
|
|
</span>
|
|
</span>
|
|
<span class="org vcardline">Isode Ltd</span>
|
|
<span class="adr">
|
|
<span class="vcardline">14 Castle Mews</span>
|
|
|
|
<span class="vcardline">
|
|
<span class="locality">Hampton, Middlesex</span>,
|
|
<span class="region"></span>
|
|
<span class="code">TW12 2NP</span>
|
|
</span>
|
|
<span class="country-name vcardline">UK</span>
|
|
</span>
|
|
<span class="vcardline">EMail: <a href="mailto:alexey.melnikov@isode.com">alexey.melnikov@isode.com</a></span>
|
|
|
|
</address>
|
|
</div><div class="avoidbreak">
|
|
<address class="vcard">
|
|
<span class="vcardline">
|
|
<span class="fn">Bernie Hoeneisen</span>
|
|
<span class="n hidden">
|
|
<span class="family-name">Hoeneisen</span>
|
|
</span>
|
|
</span>
|
|
<span class="org vcardline">Ucom Standards Track Solutions GmbH</span>
|
|
<span class="adr">
|
|
|
|
<span class="vcardline">
|
|
<span class="locality">CH-8046 Zuerich</span>,
|
|
<span class="region"></span>
|
|
<span class="code"></span>
|
|
</span>
|
|
<span class="country-name vcardline">Switzerland</span>
|
|
</span>
|
|
<span class="vcardline">Phone: +41 44 500 52 44</span>
|
|
|
|
<span class="vcardline">EMail: <a href="mailto:bernie@ietf.hoeneisen.ch%20(bernhard.hoeneisen%20AT%20ucom.ch)">bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)</a></span>
|
|
|
|
<span class="vcardline">URI: <a href="https://ucom.ch/">https://ucom.ch/</a></span>
|
|
|
|
</address>
|
|
</div><div class="avoidbreak">
|
|
<address class="vcard">
|
|
<span class="vcardline">
|
|
<span class="fn">Daniel Kahn Gillmor</span>
|
|
<span class="n hidden">
|
|
<span class="family-name">Gillmor</span>
|
|
</span>
|
|
</span>
|
|
<span class="org vcardline">American Civil Liberties Union</span>
|
|
<span class="adr">
|
|
<span class="vcardline">125 Broad St.</span>
|
|
|
|
<span class="vcardline">
|
|
<span class="locality">New York, NY</span>,
|
|
<span class="region"></span>
|
|
<span class="code">10004</span>
|
|
</span>
|
|
<span class="country-name vcardline">USA</span>
|
|
</span>
|
|
<span class="vcardline">EMail: <a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a></span>
|
|
|
|
</address>
|
|
</div>
|
|
|
|
</body>
|
|
</html>
|