Browse Source

changed section structure only, no content changes

master
Bernie Hoeneisen 2 years ago
parent
commit
f7cce9fbcc
3 changed files with 311 additions and 305 deletions
  1. +55
    -55
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
  2. +62
    -56
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.html
  3. +194
    -194
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.txt

+ 55
- 55
ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd View File

@ -719,60 +719,13 @@ Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts spam filtering.
### Message Processing {#message-processing}
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/message_orig_outer_inner_rufm.mkd}
{::include ../shared/fence-line.mkd}
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before processing
by Transport)
* OuterM(R): Outer Message at receiving side (as received by Transport)
* InnerM: Inner Message (that protection is applied to)
* RUFM: Receiving User Facing Message
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* Wrapper: MIME Header Section; with media type (message/RFC822) to
unambigously delimit the inner message from the rest of the
message.
* MIME-HSp: MIME Header Section part to describe the encryption or
signature as per {{RFC8551}}
* Trans-HF: Header Fields added in Transit (between sending and
receiving side)
* \>: taken over / copied from last column
* \=: propagates unchanged, unless something unusual (e.g. attack)
happens
* \*: HF that is often not present (also further HF may not be
present). If a HF is not present, naturally it can neither be taken
over nor propagated.
* (new) / (OrigM): HF or MIME-HSp is generated depending on the
decision in {{sending-side-step-1}}, while '(new)' / '(OrigM)'
designate the default.
#### Sending Side
### Sending Side Message Processing {#sending-side-message-processing}
For a protected message the following steps are applied before a
message is handed over to the Transport:
##### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
#### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
The entity applying protection to a message must decide:
@ -791,7 +744,7 @@ The entity applying protection to a message must decide:
obfuscated; cf. {{obfuscation-outer-HF}}.
##### Step 2: Compose the Outer Message Header Section {#sending-side-step-2}
#### Step 2: Compose the Outer Message Header Section {#sending-side-step-2}
Depending on the decision in {{sending-side-step-1}}, compose the Outer
Message Header Section. (Note that this also includes the necessary
@ -803,7 +756,7 @@ part, which depends on the protection level selected in
{{sending-side-step-1}}).
##### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
#### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
Depending on the protection level selected in {{sending-side-step-1}}
apply signature and/or encryption to the original message including
@ -816,18 +769,18 @@ Transport.
\[\[ TODO: Example \]\]
#### Receiving Side
### Receiving Side Message Processing
When a protected message is received the following steps are applied:
##### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
#### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
Depending on the protection level the received message is decrypted
and/or its signature is checked as per {{RFC8551}}.
##### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2}
#### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2}
The Receiving User Facing Message is constructed as follows:
@ -850,6 +803,53 @@ Note: It is for further study whether and, if yes, how the Outer
preserved for the user.
### Header Field Flow
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/message_orig_outer_inner_rufm.mkd}
{::include ../shared/fence-line.mkd}
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before processing
by Transport)
* OuterM(R): Outer Message at receiving side (as received by Transport)
* InnerM: Inner Message (that protection is applied to)
* RUFM: Receiving User Facing Message
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* Wrapper: MIME Header Section; with media type (message/RFC822) to
unambigously delimit the inner message from the rest of the
message.
* MIME-HSp: MIME Header Section part to describe the encryption or
signature as per {{RFC8551}}
* Trans-HF: Header Fields added in Transit (between sending and
receiving side)
* \>: taken over / copied from last column
* \=: propagates unchanged, unless something unusual (e.g. attack)
happens
* \*: HF that is often not present (also further HF may not be
present). If a HF is not present, naturally it can neither be taken
over nor propagated.
* (new) / (OrigM): HF or MIME-HSp is generated depending on the
decision in {{sending-side-step-1}}, while '(new)' / '(OrigM)'
designate the default.
## Backward Compatibility Use Case {#backward-compatibility-use-case}
@ -963,7 +963,7 @@ header field may appear in up to three different variants:
* Impact on spam filtering, if HFs are obfuscated
({{obfuscation-outer-HF}})
* More examples (e.g. in {{message-processing}})
* More examples (e.g. in {{sending-side-message-processing}})
* Should Outer Message Header Section (as received) be preserved for
the user? ({{receiving-side-step-2}})


+ 62
- 56
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.html View File

@ -393,7 +393,9 @@
<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 Message Processing">
<link href="#rfc.section.4.1.5" rel="Chapter" title="4.1.5 Sending Side Message Processing">
<link href="#rfc.section.4.1.6" rel="Chapter" title="4.1.6 Receiving Side Message Processing">
<link href="#rfc.section.4.1.7" rel="Chapter" title="4.1.7 Header Field Flow">
<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">
@ -508,7 +510,11 @@
</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">Message Processing</a>
<li>4.1.5. <a href="#rfc.section.4.1.5">Sending Side Message Processing</a>
</li>
<li>4.1.6. <a href="#rfc.section.4.1.6">Receiving Side Message Processing</a>
</li>
<li>4.1.7. <a href="#rfc.section.4.1.7">Header Field Flow</a>
</li>
</ul><li>4.2. <a href="#rfc.section.4.2">Backward Compatibility Use Case</a>
</li>
@ -881,9 +887,56 @@ signature.
<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="#message-processing" id="message-processing">Message Processing</a>
<a href="#rfc.section.4.1.5">4.1.5.</a> <a href="#sending-side-message-processing" id="sending-side-message-processing">Sending Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.5.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.5.1">
<a href="#rfc.section.4.1.5.1">4.1.5.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.5.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.5.2">
<a href="#rfc.section.4.1.5.2">4.1.5.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.5.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.5.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.5.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.5.1</a>).</p>
<h1 id="rfc.section.4.1.5.3">
<a href="#rfc.section.4.1.5.3">4.1.5.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.5.3.p.1">Depending on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1</a> apply signature and/or encryption to the original message including the wrapper (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and put the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.5.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.5.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.6">
<a href="#rfc.section.4.1.6">4.1.6.</a> <a href="#receiving-side-message-processing" id="receiving-side-message-processing">Receiving Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.6.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.6.1">
<a href="#rfc.section.4.1.6.1">4.1.6.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.6.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.6.2">
<a href="#rfc.section.4.1.6.2">4.1.6.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.6.2.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.6.2.p.3">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.6.2.p.4">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<p id="rfc.section.4.1.6.2.p.5">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.1.7">
<a href="#rfc.section.4.1.7">4.1.7.</a> <a href="#header-field-flow" id="header-field-flow">Header Field Flow</a>
</h1>
<p id="rfc.section.4.1.5.p.1">The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:</p>
<p id="rfc.section.4.1.7.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
@ -912,7 +965,7 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
&lt;Signature&gt;* (new)= &lt;Signature&gt;
</pre>
<p id="rfc.section.4.1.5.p.2">Legend:</p>
<p id="rfc.section.4.1.7.p.2">Legend:</p>
<p></p>
<ul>
@ -928,55 +981,8 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<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 HF 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.5.1.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
</ul>
<h1 id="rfc.section.4.1.5.1">
<a href="#rfc.section.4.1.5.1">4.1.5.1.</a> <a href="#sending-side" id="sending-side">Sending Side</a>
</h1>
<p id="rfc.section.4.1.5.1.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.5.1.1">
<a href="#rfc.section.4.1.5.1.1">4.1.5.1.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.5.1.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.5.1.2">
<a href="#rfc.section.4.1.5.1.2">4.1.5.1.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.5.1.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.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.5.1.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.5.1.1</a>).</p>
<h1 id="rfc.section.4.1.5.1.3">
<a href="#rfc.section.4.1.5.1.3">4.1.5.1.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.5.1.3.p.1">Depending on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.1</a> apply signature and/or encryption to the original message including the wrapper (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and put the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.5.1.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.5.1.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.5.2">
<a href="#rfc.section.4.1.5.2">4.1.5.2.</a> <a href="#receiving-side" id="receiving-side">Receiving Side</a>
</h1>
<p id="rfc.section.4.1.5.2.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.5.2.1">
<a href="#rfc.section.4.1.5.2.1">4.1.5.2.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.5.2.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.5.2.2">
<a href="#rfc.section.4.1.5.2.2">4.1.5.2.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.5.2.2.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>
<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.5.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
</ul>
<p id="rfc.section.4.1.5.2.2.p.3">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.5.2.2.p.4">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<p id="rfc.section.4.1.5.2.2.p.5">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>
@ -1112,9 +1118,9 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<ul>
<li>Decide on format of obfuscated HFs, in particular Date HF (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>)</li>
<li>Impact on spam filtering, if HFs are obfuscated (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>)</li>
<li>More examples (e.g. in <a href="#message-processing" class="xref">Section 4.1.5</a>)</li>
<li>Should Outer Message Header Section (as received) be preserved for the user? (<a href="#receiving-side-step-2" class="xref">Section 4.1.5.2.2</a>)</li>
<li>Do we need to take special care of HFs that may appear multiple times, e.g. Received HF? (<a href="#receiving-side-step-2" class="xref">Section 4.1.5.2.2</a>)</li>
<li>More examples (e.g. in <a href="#sending-side-message-processing" class="xref">Section 4.1.5</a>)</li>
<li>Should Outer Message Header Section (as received) be preserved for the user? (<a href="#receiving-side-step-2" class="xref">Section 4.1.6.2</a>)</li>
<li>Do we need to take special care of HFs that may appear multiple times, e.g. Received HF? (<a href="#receiving-side-step-2" class="xref">Section 4.1.6.2</a>)</li>
<li>Change adding Content-Type header field parameter &#8220;forwarded&#8221; from SHOULD to MUST (<a href="#wrapper" class="xref">Section 4.1.3</a>)?</li>
<li>Decide on whether or not merge requirements from <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a> into this document.</li>
<li>Decide what parts of <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> to merge into this document.</li>


+ 194
- 194
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.txt View File

@ -65,8 +65,8 @@ Internet-Draft Header Protection S/MIME June 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6
@ -84,14 +84,16 @@ Table of Contents
4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 13
4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 13
4.1.5. Message Processing . . . . . . . . . . . . . . . . . 15
4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 19
4.1.5. Sending Side Message Processing . . . . . . . . . . . 15
4.1.6. Receiving Side Message Processing . . . . . . . . . . 16
4.1.7. Header Field Flow . . . . . . . . . . . . . . . . . . 17
4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Additional information . . . . . . . . . . . . . . . 21
@ -100,12 +102,10 @@ Table of Contents
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the
email headers section or selected header fields (HF) from the domain-
level perspective, specifically DomainKeys Identified Mail (DKIM)
@ -114,6 +114,12 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 2]
Internet-Draft Header Protection S/MIME June 2020
1. Introduction
A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the
email headers section or selected header fields (HF) from the domain-
level perspective, specifically DomainKeys Identified Mail (DKIM)
[RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
based Message Authentication, Reporting, and Conformance (DMARC)
[RFC7489]. These protocols, while essential to responding to a range
@ -156,12 +162,6 @@ Internet-Draft Header Protection S/MIME June 2020
the upcoming discussions on. In any case, the final solution is to
be determined by the IETF LAMPS WG.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
@ -170,6 +170,12 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 3]
Internet-Draft Header Protection S/MIME June 2020
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terms
The following terms are defined for the scope of this document:
@ -212,12 +218,6 @@ Internet-Draft Header Protection S/MIME June 2020
Header Section and is separated from the Header Section by an
empty line (i.e., a line with nothing preceding the CRLF); cf
[RFC5322]. It is the (bottom) section of Message containing the
payload of a Message. Typically, the Body consists of a
(multipart) MIME [RFC2045] construct.
o MIME Header Fields: Header Fields describing the MIME structure of
its body as defined in [RFC2045].
@ -226,6 +226,12 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 4]
Internet-Draft Header Protection S/MIME June 2020
payload of a Message. Typically, the Body consists of a
(multipart) MIME [RFC2045] construct.
o MIME Header Fields: Header Fields describing the MIME structure of
its body as defined in [RFC2045].
o MIME Header Section (part): The collection of MIME Header Fields.
"MIME Header Section" refers to a Header Sections that contains
only MIME Header Fields, whereas "MIME Header Section part" refers
@ -268,12 +274,6 @@ Internet-Draft Header Protection S/MIME June 2020
o Protected Message: A message that protection measures of any
Protection Levels have been applied to.
o Unprotected: Unprotected refers to the parts of a message where no
protection measures of any Protection Levels have been applied to.
o Unprotected Message: A message that no protection measures of any
Protection Levels have been applied to.
@ -282,6 +282,12 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 5]
Internet-Draft Header Protection S/MIME June 2020
o Unprotected: Unprotected refers to the parts of a message where no
protection measures of any Protection Levels have been applied to.
o Unprotected Message: A message that no protection measures of any
Protection Levels have been applied to.
o Data Minimization: Data spareness and hiding all technically
concealable information whenever possible.
@ -323,12 +329,6 @@ Internet-Draft Header Protection S/MIME June 2020
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/MIME, PGP/MIME or
any other technology is used to achieve HP.
@ -338,6 +338,9 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 6]
Internet-Draft Header Protection S/MIME June 2020
These use cases apply independently of whether S/MIME, PGP/MIME or
any other technology is used to achieve HP.
3.1. Interactions
3.1.1. Main Case for Header Protection
@ -384,9 +387,6 @@ Internet-Draft Header Protection S/MIME June 2020
Furthermore, it is likely that PGP/MIME [RFC3156] will also take over
this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. Section 3.2):
Hoeneisen & Melnikov Expires December 28, 2020 [Page 7]
@ -394,6 +394,9 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 7]
Internet-Draft Header Protection S/MIME June 2020
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. Section 3.2):
Sending and receiving sides SHOULD implement "signature and
encryption", which is the default to use on the sending side.
@ -440,9 +443,6 @@ Internet-Draft Header Protection S/MIME June 2020
mailing applications might display the Inner Message as attachment
otherwise.
The MIME structure of an Email message looks as follows:
Hoeneisen & Melnikov Expires December 28, 2020 [Page 8]
@ -450,6 +450,8 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 8]
Internet-Draft Header Protection S/MIME June 2020
The MIME structure of an Email message looks as follows:
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
@ -496,8 +498,6 @@ Internet-Draft Header Protection S/MIME June 2020
@ -812,36 +812,105 @@ Internet-Draft Header Protection S/MIME June 2020
Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts spam filtering.
4.1.5. Message Processing
4.1.5. Sending Side Message Processing
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
For a protected message the following steps are applied before a
message is handed over to the Transport:
4.1.5.1. Step 1: Decide on Protection Level and Information Disclosure
The entity applying protection to a message must decide:
o 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.
o 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. Section 4.1.4.
o 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.
Section 4.1.4.1.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 15]
Internet-Draft Header Protection S/MIME June 2020
4.1.5.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Section 4.1.5.1, compose the Outer
Message Header Section. (Note that this also includes the necessary
MIME Header Section part for the following protection layer.)
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
Section 4.1.5.1).
4.1.5.3. Step 3: Apply Protection to the Original Message
Depending on the protection level selected in Section 4.1.5.1 apply
signature and/or encryption to the original message including the
wrapper (as per [RFC8551]) and put the result to the message as Outer
Message Body.
The resulting (Outer) Message is then typically handed over to the
Transport.
[[ TODO: Example ]]
4.1.6. Receiving Side Message Processing
When a protected message is received the following steps are applied:
4.1.6.1. Step 1: Decrypt message and/or check signature
Depending on the protection level the received message is decrypted
and/or its signature is checked as per [RFC8551].
4.1.6.2. Step 2: Construct the Receiving User Facing Message
Hoeneisen & Melnikov Expires December 28, 2020 [Page 15]
The Receiving User Facing Message is constructed as follows:
o 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).
o The Body of the Receiving User Facing Message Body MUST be the
same as the Inner Message Body.
The resulting message is handed over for further processing, which
typically involves rendering it to the user.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 16]
Internet-Draft Header Protection S/MIME June 2020
[[ TODO: Do we need to take special care for HFs, which may appear
multiple times, e.g. Received HF? ]]
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.
4.1.7. Header Field Flow
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
OrigM InnerM Outer(S) OuterM(R) RUFM
<Trans-HF> > <Trans-HF>
@ -877,6 +946,14 @@ Internet-Draft Header Protection S/MIME June 2020
o OuterM(R): Outer Message at receiving side (as received by
Transport)
Hoeneisen & Melnikov Expires December 28, 2020 [Page 17]
Internet-Draft Header Protection S/MIME June 2020
o InnerM: Inner Message (that protection is applied to)
o RUFM: Receiving User Facing Message
@ -891,13 +968,6 @@ Internet-Draft Header Protection S/MIME June 2020
o MIME-HSp: MIME Header Section part to describe the encryption or
signature as per [RFC8551]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 16]
Internet-Draft Header Protection S/MIME June 2020
o Trans-HF: Header Fields added in Transit (between sending and
receiving side)
@ -911,105 +981,9 @@ Internet-Draft Header Protection S/MIME June 2020
taken over nor propagated.
o (new) / (OrigM): HF or MIME-HSp is generated depending on the
decision in Section 4.1.5.1.1, while '(new)' / '(OrigM)' designate
decision in Section 4.1.5.1, while '(new)' / '(OrigM)' designate
the default.
4.1.5.1. Sending Side
For a protected message the following steps are applied before a
message is handed over to the Transport:
4.1.5.1.1. Step 1: Decide on Protection Level and Information
Disclosure
The entity applying protection to a message must decide:
o 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.
o 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. Section 4.1.4.
o 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.
Section 4.1.4.1.
4.1.5.1.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Section 4.1.5.1.1, compose the Outer
Message Header Section. (Note that this also includes the necessary
MIME Header Section part for the following protection layer.)
Outer Header Fields that are not obfuscated SHOULD contain the same
values as in the Original Message (except for MIME Header
Hoeneisen & Melnikov Expires December 28, 2020 [Page 17]
Internet-Draft Header Protection S/MIME June 2020
Section part, which depends on the protection level selected in
Section 4.1.5.1.1).
4.1.5.1.3. Step 3: Apply Protection to the Original Message
Depending on the protection level selected in Section 4.1.5.1.1 apply
signature and/or encryption to the original message including the
wrapper (as per [RFC8551]) and put the result to the message as Outer
Message Body.
The resulting (Outer) Message is then typically handed over to the
Transport.
[[ TODO: Example ]]
4.1.5.2. Receiving Side
When a protected message is received the following steps are applied:
4.1.5.2.1. Step 1: Decrypt message and/or check signature
Depending on the protection level the received message is decrypted
and/or its signature is checked as per [RFC8551].
4.1.5.2.2. Step 2: Construct the Receiving User Facing Message
The Receiving User Facing Message is constructed as follows:
o 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).
o The Body of the Receiving User Facing Message Body MUST be the
same as the Inner Message Body.
The resulting message is handed over for further processing, which
typically involves rendering it to the user.
[[ TODO: Do we need to take special care for HFs, which may appear
multiple times, e.g. Received HF? ]]
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.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 18]
Internet-Draft Header Protection S/MIME June 2020
4.2. Backward Compatibility Use Case
[I-D.autocrypt-lamps-protected-headers] describes a possibility to
@ -1029,6 +1003,13 @@ Internet-Draft Header Protection S/MIME June 2020
[I-D.autocrypt-lamps-protected-headers] may serve as a basis to
mitigate those (backward compatibility use case).
Hoeneisen & Melnikov Expires December 28, 2020 [Page 18]
Internet-Draft Header Protection S/MIME June 2020
Another variant of backward compatibility has been implemented by pEp
[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
implemented this for PGP/MIME (but not yet S/MIME).
@ -1055,17 +1036,6 @@ Internet-Draft Header Protection S/MIME June 2020
Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
Chuang.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 19]
Internet-Draft Header Protection S/MIME June 2020
9. References
9.1. Normative References
@ -1086,6 +1056,16 @@ Internet-Draft Header Protection S/MIME June 2020
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 19]
Internet-Draft Header Protection S/MIME June 2020
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
@ -1113,15 +1093,6 @@ Internet-Draft Header Protection S/MIME June 2020
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 20]
Internet-Draft Header Protection S/MIME June 2020
[pEp.mixnet]
pEp Foundation, "Mixnet", June 2020,
<https://dev.pep.foundation/Mixnet>.
@ -1140,6 +1111,17 @@ Internet-Draft Header Protection S/MIME June 2020
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 20]
Internet-Draft Header Protection S/MIME June 2020
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
@ -1168,16 +1150,6 @@ A.1. Stored Variants of Messages with Bcc
2. The message(s) sent to the recipient addresses in the Bcc header
field, which depends on the implementation:
Hoeneisen & Melnikov Expires December 28, 2020 [Page 21]
Internet-Draft Header Protection S/MIME June 2020
a) One message for each recipient in the Bcc header field
separately with a Bcc header field containing only the address of
the recipient it is sent to
@ -1194,6 +1166,18 @@ Internet-Draft Header Protection S/MIME June 2020
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 21]
Internet-Draft Header Protection S/MIME June 2020
Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
@ -1216,24 +1200,14 @@ Appendix C. Open Issues
o More examples (e.g. in Section 4.1.5)
o Should Outer Message Header Section (as received) be preserved for
the user? (Section 4.1.5.2.2)
the user? (Section 4.1.6.2)
o Do we need to take special care of HFs that may appear multiple
times, e.g. Received HF? (Section 4.1.5.2.2)
times, e.g. Received HF? (Section 4.1.6.2)
o Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST (Section 4.1.3)?
Hoeneisen & Melnikov Expires December 28, 2020 [Page 22]
Internet-Draft Header Protection S/MIME June 2020
o Decide on whether or not merge requirements from
[I-D.ietf-lamps-header-protection-requirements] into this
document.
@ -1252,6 +1226,14 @@ Internet-Draft Header Protection S/MIME June 2020
o Security Considerations Section 5
Hoeneisen & Melnikov Expires December 28, 2020 [Page 22]
Internet-Draft Header Protection S/MIME June 2020
Authors' Addresses
Bernie Hoeneisen
@ -1282,6 +1264,24 @@ Authors' Addresses


Loading…
Cancel
Save