Browse Source

structure changed, same content

master
Bernie Hoeneisen 2 years ago
parent
commit
35b7a9be86
3 changed files with 252 additions and 238 deletions
  1. +65
    -59
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
  2. +60
    -53
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.html
  3. +127
    -126
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.txt

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

@ -686,6 +686,69 @@ Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts spam filtering.
### Receiving User Facing Message Header Fields {#rufm-hf}
The Receiving User Facing Message is constructed as follows:
* 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).
* The Body of the Receiving User Facing Message Body MUST be the same
as the Inner Message Body.
\[\[ TODO: Do we need to take special care for HFs, which may appear
multiple times, e.g. Received HF? \]\]
### 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.
### Sending Side Message Processing {#sending-side-message-processing}
For a protected message the following steps are applied before a
@ -750,75 +813,18 @@ and/or its signature is checked as per {{RFC8551}}.
#### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2}
The Receiving User Facing Message is constructed as follows:
* 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).
* The Body of the Receiving User Facing Message Body MUST be the same
as the Inner Message Body.
The Receiving User Facing Message is constructed according to
{{rufm-hf}}.
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.
### 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}
{{I-D.autocrypt-lamps-protected-headers}} describes a possibility to


+ 60
- 53
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.html View File

@ -393,9 +393,10 @@
<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 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.1.5" rel="Chapter" title="4.1.5 Receiving User Facing Message Header Fields">
<link href="#rfc.section.4.1.6" rel="Chapter" title="4.1.6 Header Field Flow">
<link href="#rfc.section.4.1.7" rel="Chapter" title="4.1.7 Sending Side Message Processing">
<link href="#rfc.section.4.1.8" rel="Chapter" title="4.1.8 Receiving Side Message Processing">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Backward Compatibility Use Case">
<link href="#rfc.section.5" rel="Chapter" title="5 Security Considerations">
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations">
@ -510,11 +511,13 @@
</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">Sending Side Message Processing</a>
<li>4.1.5. <a href="#rfc.section.4.1.5">Receiving User Facing Message Header Fields</a>
</li>
<li>4.1.6. <a href="#rfc.section.4.1.6">Receiving Side Message Processing</a>
<li>4.1.6. <a href="#rfc.section.4.1.6">Header Field Flow</a>
</li>
<li>4.1.7. <a href="#rfc.section.4.1.7">Header Field Flow</a>
<li>4.1.7. <a href="#rfc.section.4.1.7">Sending Side Message Processing</a>
</li>
<li>4.1.8. <a href="#rfc.section.4.1.8">Receiving Side Message Processing</a>
</li>
</ul><li>4.2. <a href="#rfc.section.4.2">Backward Compatibility Use Case</a>
</li>
@ -885,56 +888,20 @@ 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="#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 set 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>
<a href="#rfc.section.4.1.5">4.1.5.</a> <a href="#rufm-hf" id="rufm-hf">Receiving User Facing Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.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 id="rfc.section.4.1.5.p.1">The Receiving User Facing Message is constructed as follows:</p>
<p></p>
<ul>
<li>The Header Section of the Receiving User Facing Message MUST consist of the Outer Message Header Fields that are not contained in the Inner Message Header Section, and the Inner Message Header Fields (i.e. the Inner Message Header Field MUST always take precedence).</li>
<li>The Body of the Receiving User Facing Message Body MUST be the same as the Inner Message Body.</li>
</ul>
<p id="rfc.section.4.1.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>
<p id="rfc.section.4.1.5.p.3">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<h1 id="rfc.section.4.1.6">
<a href="#rfc.section.4.1.6">4.1.6.</a> <a href="#header-field-flow" id="header-field-flow">Header Field Flow</a>
</h1>
<p id="rfc.section.4.1.7.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.6.p.1">The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:</p>
<pre>
OrigM InnerM Outer(S) OuterM(R) RUFM
@ -963,7 +930,7 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
&lt;Signature&gt;* (new)= &lt;Signature&gt;
</pre>
<p id="rfc.section.4.1.7.p.2">Legend:</p>
<p id="rfc.section.4.1.6.p.2">Legend:</p>
<p></p>
<ul>
@ -979,8 +946,48 @@ 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</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
<li>(new) / (OrigM): HF or MIME-HSp is generated depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
</ul>
<h1 id="rfc.section.4.1.7">
<a href="#rfc.section.4.1.7">4.1.7.</a> <a href="#sending-side-message-processing" id="sending-side-message-processing">Sending Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.7.p.1">For a protected message the following steps are applied before a message is handed over to the Transport:</p>
<h1 id="rfc.section.4.1.7.1">
<a href="#rfc.section.4.1.7.1">4.1.7.1.</a> <a href="#sending-side-step-1" id="sending-side-step-1">Step 1: Decide on Protection Level and Information Disclosure</a>
</h1>
<p id="rfc.section.4.1.7.1.p.1">The entity applying protection to a message must decide:</p>
<p></p>
<ul>
<li>Which Protection Level (signature and/or encryption) is applied to the message? This depends on user request and/or local policy as well as availability of cryptographic keys.</li>
<li>Which Header Fields of the Orignial Message shall be part of the Outer Message Header Section? This typically depends on local policy. By default the Essential Header Fields are part of the Outer Message Header Section; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.4</a>.</li>
<li>Which of these Header Fields are to be obfuscated? This depends on local policy and/or specific Privacy requirements of the user. By default only the Subject Header Field is obfuscated; cf. <a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>.</li>
</ul>
<h1 id="rfc.section.4.1.7.2">
<a href="#rfc.section.4.1.7.2">4.1.7.2.</a> <a href="#sending-side-step-2" id="sending-side-step-2">Step 2: Compose the Outer Message Header Section</a>
</h1>
<p id="rfc.section.4.1.7.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>, compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.)</p>
<p id="rfc.section.4.1.7.2.p.2">Outer Header Fields that are not obfuscated should contain the same values as in the Original Message (except for MIME Header Section part, which depends on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a>).</p>
<h1 id="rfc.section.4.1.7.3">
<a href="#rfc.section.4.1.7.3">4.1.7.3.</a> <a href="#sending-side-step-3" id="sending-side-step-3">Step 3: Apply Protection to the Original Message</a>
</h1>
<p id="rfc.section.4.1.7.3.p.1">Depending on the Protection Level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.7.1</a> apply signature and/or encryption to the Original Message including the wrapper (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and set the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.7.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.7.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.8">
<a href="#rfc.section.4.1.8">4.1.8.</a> <a href="#receiving-side-message-processing" id="receiving-side-message-processing">Receiving Side Message Processing</a>
</h1>
<p id="rfc.section.4.1.8.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.8.1">
<a href="#rfc.section.4.1.8.1">4.1.8.1.</a> <a href="#receiving-side-step-1" id="receiving-side-step-1">Step 1: Decrypt message and/or check signature</a>
</h1>
<p id="rfc.section.4.1.8.1.p.1">Depending on the protection level the received message is decrypted and/or its signature is checked as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<h1 id="rfc.section.4.1.8.2">
<a href="#rfc.section.4.1.8.2">4.1.8.2.</a> <a href="#receiving-side-step-2" id="receiving-side-step-2">Step 2: Construct the Receiving User Facing Message</a>
</h1>
<p id="rfc.section.4.1.8.2.p.1">The Receiving User Facing Message is constructed according to <a href="#rufm-hf" class="xref">Section 4.1.5</a>.</p>
<p id="rfc.section.4.1.8.2.p.2">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.8.2.p.3">Note: It is for further study whether and, if yes, how the Outer Message Header Section (as received from the Transport) is preserved for the user.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#backward-compatibility-use-case" id="backward-compatibility-use-case">Backward Compatibility Use Case</a>
</h1>
@ -1123,9 +1130,9 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<li>Ensure &#8220;protected header&#8221; (Ex-Memory-Hole) option is (fully) compliant with the MIME standard, in particuar also <a href="#RFC2046" class="xref">[RFC2046]</a>, Section 5.1. (Multipart Media Type) <a href="#option-ex-memory-hole" class="xref">Section 4.1.1.2</a>.</li>
<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="#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>More examples (e.g. in <a href="#sending-side-message-processing" class="xref">Section 4.1.7</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.8.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.8.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>


+ 127
- 126
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.txt View File

@ -84,9 +84,10 @@ 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. Sending Side Message Processing . . . . . . . . . . . 15
4.1.6. Receiving Side Message Processing . . . . . . . . . . 16
4.1.7. Header Field Flow . . . . . . . . . . . . . . . . . . 17
4.1.5. Receiving User Facing Message Header Fields . . . . . 15
4.1.6. Header Field Flow . . . . . . . . . . . . . . . . . . 15
4.1.7. Sending Side Message Processing . . . . . . . . . . . 17
4.1.8. Receiving Side Message Processing . . . . . . . . . . 18
4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
@ -812,69 +813,7 @@ 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. Sending Side Message Processing
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 30, 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 set 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
4.1.5. Receiving User Facing Message Header Fields
The Receiving User Facing Message is constructed as follows:
@ -887,30 +826,23 @@ Internet-Draft Header Protection S/MIME June 2020
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 30, 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
4.1.6. Header Field Flow
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
Hoeneisen & Melnikov Expires December 30, 2020 [Page 15]
Internet-Draft Header Protection S/MIME June 2020
OrigM InnerM Outer(S) OuterM(R) RUFM
<Trans-HF> > <Trans-HF>
@ -946,14 +878,6 @@ Internet-Draft Header Protection S/MIME June 2020
o OuterM(R): Outer Message at receiving side (as received by
Transport)
Hoeneisen & Melnikov Expires December 30, 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
@ -968,6 +892,13 @@ 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 30, 2020 [Page 16]
Internet-Draft Header Protection S/MIME June 2020
o Trans-HF: Header Fields added in Transit (between sending and
receiving side)
@ -981,9 +912,85 @@ 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, while '(new)' / '(OrigM)' designate
decision in Section 4.1.7.1, while '(new)' / '(OrigM)' designate
the default.
4.1.7. Sending Side Message Processing
For a protected message the following steps are applied before a
message is handed over to the Transport:
4.1.7.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.7.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Section 4.1.7.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 30, 2020 [Page 17]
Internet-Draft Header Protection S/MIME June 2020
Section part, which depends on the protection level selected in
Section 4.1.7.1).
4.1.7.3. Step 3: Apply Protection to the Original Message
Depending on the Protection Level selected in Section 4.1.7.1 apply
signature and/or encryption to the Original Message including the
wrapper (as per [RFC8551]) and set 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.8. Receiving Side Message Processing
When a protected message is received the following steps are applied:
4.1.8.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.8.2. Step 2: Construct the Receiving User Facing Message
The Receiving User Facing Message is constructed according to
Section 4.1.5.
The resulting message is handed over for further processing, which
typically involves rendering it to the user.
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.2. Backward Compatibility Use Case
[I-D.autocrypt-lamps-protected-headers] describes a possibility to
@ -995,13 +1002,7 @@ Internet-Draft Header Protection S/MIME June 2020
of this problem with S/MIME implementations is still unclear. (Note:
At this time, none of the samples in
[I-D.autocrypt-lamps-protected-headers] applies header protection as
specified in Section 3.1 of [RFC8551], which is wrapping as Media
Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver reveal, the Legacy Display format described in
[I-D.autocrypt-lamps-protected-headers] may serve as a basis to
mitigate those (backward compatibility use case).
@ -1010,6 +1011,14 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 18]
Internet-Draft Header Protection S/MIME June 2020
specified in Section 3.1 of [RFC8551], which is wrapping as Media
Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver reveal, the Legacy Display format described in
[I-D.autocrypt-lamps-protected-headers] may serve as a basis to
mitigate those (backward compatibility use case).
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).
@ -1051,14 +1060,6 @@ Internet-Draft Header Protection S/MIME June 2020
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
Hoeneisen & Melnikov Expires December 30, 2020 [Page 19]
@ -1066,6 +1067,11 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 19]
Internet-Draft Header Protection S/MIME June 2020
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
@ -1107,11 +1113,6 @@ Internet-Draft Header Protection S/MIME June 2020
DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
@ -1122,6 +1123,10 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 20]
Internet-Draft Header Protection S/MIME June 2020
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
@ -1167,10 +1172,6 @@ A.1. Stored Variants of Messages with Bcc
which does not include a Bcc header field (this message is
identical to 1. / cf. above)
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
Hoeneisen & Melnikov Expires December 30, 2020 [Page 21]
@ -1178,6 +1179,10 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 21]
Internet-Draft Header Protection S/MIME June 2020
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
The most privacy preserving is to standardize 2a, as in the other
cases (2b and 2c) information about hidden recipients is revealed via
keys. In any case the message has to be cloned and adjusted
@ -1206,13 +1211,13 @@ Appendix C. Open Issues
o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
o More examples (e.g. in Section 4.1.5)
o More examples (e.g. in Section 4.1.7)
o Should Outer Message Header Section (as received) be preserved for
the user? (Section 4.1.6.2)
the user? (Section 4.1.8.2)
o Do we need to take special care of HFs that may appear multiple
times, e.g. Received HF? (Section 4.1.6.2)
times, e.g. Received HF? (Section 4.1.8.2)
o Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST (Section 4.1.3)?
@ -1221,10 +1226,6 @@ Appendix C. Open Issues
[I-D.ietf-lamps-header-protection-requirements] into this
document.
o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
merge into this document.
o Enhance Introduction and Problem Statement sections
@ -1234,6 +1235,11 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 22]
Internet-Draft Header Protection S/MIME June 2020
o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
merge into this document.
o Enhance Introduction and Problem Statement sections
o Decide on whether or not specification for more legacy HP
requirements should be added to this document
@ -1277,11 +1283,6 @@ Authors' Addresses


Loading…
Cancel
Save