Header Protection for S/MIME

3.1.2.1. Receiving Side MIME-Conformant

The sending side (fully) supports Header Protection as specified in this document, while the receiving side does not support this specification. However, the receiving side is MIME-conformant according to [RFC2045], ff. (cf. Section 3.1.2).¶

This use case is specified in Section 4.2.1.¶

Note: This case should perform as expected if the sending side applies this specification as outlined in Section 4.1.¶

[[ TODO: Verify once solution is stable and update last sentence. ]]¶

3.1.2.2. Receiving Side Not MIME-Conformant

The sending side (fully) supports Header Protection as specified in this document, while the receiving side does not support this specification. Furthermore, the receiving side is not MIME-conformant according to [RFC2045], ff. (cf. Section 3.1.2).¶

This use case is specified in Section 4.2.2.¶

4.1.1.1. Introduction

As per S/MIME version 3.1 and later (cf. [RFC8551]), 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.¶

To help the receiving side to distinguish between a forwarded and a wrapped message, the Content-Type header field parameter "forwarded" is added as defined in [I-D.melnikov-iana-reg-forwarded].¶

The simplified (cryptographic overhead not shown) MIME structure of such an Email Message looks as follows:¶

  <Outer Message Header Section (unprotected)>

  <Outer Message Body (protected)>

    <MIME Header Section (wrapper)>

      <Inner Message Header Section>

      <Inner Message Body>

The following example demonstrates how an Original Message might be protected, i.e., the Original Message is contained as Inner Message in the Protected Body of an Outer Message. It illustrates the first Body part (of the Outer Message) as a "multipart/signed" (application/pkcs7-signature) media type:¶

Lines are prepended as follows:¶

• "O: " Outer Message Header Section¶
• "I: " Message Header Section¶
• "W: " Wrapper (MIME Header Section)¶

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
  O: Subject: Meeting at my place
  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  O: To: somebody@example.net
  O: MIME-Version: 1.0
  O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  O:  protocol="application/pkcs7-signature";
  O:  boundary=boundary-AM

     This is a multipart message in MIME format.
     --boundary-AM
  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@m.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.

     --boundary-AM
     Content-Transfer-Encoding: base64
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --boundary-AM--

The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the wrapper (MIME Header Section) and the Inner Message (Header Section and Body).¶

The wrapper is a simple MIME Header Section with media type "message/rfc822" containing a Content-Type header field parameter "forwarded=no" followed by an empty line.¶

If the source is an Original (message/rfc822) Message, the Inner Message Header Section is typically the same as (or a subset of) the Original Message Header Section, and the Inner Message Body is typically the same as the Original Message Body.¶

The Inner Message itself may contain any MIME structure.¶

Note: It is still to be decided by the LAMPS WG whether or not to recommend an alternative MIME format as described in Appendix C.1.1.1 (instead of the currently standardized and above defined format).¶

4.1.2.1. Composing a Cryptographically-Protected Message Without Header Protection

[I-D.dkg-lamps-e2e-mail-guidance] describes the typical process for a legacy crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference:¶

• origbody: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has structural headers (Content-*) present.¶
• origheaders: the intended non-structural headers for the message, represented here as a list of (h,v) pairs, where h is a header field name and v is the associated value. Note that these are header fields that the MUA intends to be visible to the recipient of the message. In particular, if the MUA uses the Bcc header during composition, but plans to omit it from the message (see section 3.6.3 of [RFC5322]), it will not be in origheaders.¶
• crypto: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.¶

The algorithm returns a MIME object that is ready to be injected into the mail system:¶

• Apply crypto to origbody, yielding MIME tree output¶

• For each header name and value (h,v) in origheaders:¶

  • Add header h of output with value v¶
• Return output¶

4.1.2.2. Header Confidentiality Policy

When composing an encrypted message with protected headers, the composing MUA needs a Header Confidentialiy Policy. In this document, we represent that Header Confidentiality Policy as a function hcp:¶

• hcp(name, val_in) --> val_out: this function takes a header field name name and initial value val_in as arguments, and returns a replacement header value val_out. If val_out is the special value null, it mean that the header in question should be omitted from the set of headers visible outside the Cryptographic Envelope.¶

For example, an MUA that only obscures the Subject header field by replacing it with the literal string [...] and does not offer confidentiality to any other header fields would be represented as (in pseudocode):¶

hcp(name, val_in) --> val_out: if name is 'Subject': return '[...]' else: return val_in ¶

Note that such a policy is only needed when the end-to-end protections include encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protections (integrity and authenticity), as they are simply uniformly applied so that all header fields known by the sender have these protections.¶

This asymmetry is an unfortunate consequence of complexities in message delivery systems, some of which may reject, drop, or delay messages where all headers are removed from the top-level MIME object.¶

This document does not mandate any particular Header Confidentiality Policy, though it offers guidance for MUA implementers in selecting one in Section 4.1.3. Future documents may recommend or mandate such a policy for an MUA with specific needs. Such a recommendation might be motivated by descriptions of metadata-derived attacks, or stem from research about message deliverability, or describe new signalling mechanisms, but these topics are out of scope for this document.¶

4.1.2.3. Composing with "Wrapped Message" Header Protection

To compose a message using "Wrapped Message" header protection, we use those inputs described in Section 4.1.2.1 plus the Header Confidentiality Policy hcp defined in Section 4.1.2.2. The new algorithm is:¶

• For header name and value (h,v) in origheaders:¶

  • Add header h of origbody with value v¶

• If any of the header fields in origbody, including headers in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see section section 3.7 of [RFC6532]):¶

  • Let payload be a new MIME part with one header: Content-Type: message/global; forwarded=no, and whose body is origbody.¶

• Else:¶

  • Let payload be a new MIME part with one header: Content-Type: message/rfc822; forwarded=no, and whose body is origbody.¶
• Apply crypto to payload, yielding MIME tree output¶

• If crypto contains encryption:¶

  • Create new empty list of header field names and values newh¶

  • For header name and value (h,v) in origheaders:¶

    • Let newval be hcp(h, v)¶

    • If newval is not null:¶

      • Append (h,newval) to newh¶
  • Set origheaders to newh¶

• For header name and value (h,v) in origheaders:¶

  • Add header h of output with value v¶
• Return output¶

Note that the Header Confidentiality Policy hcp is ignored if crypto does not contain encryption. This is by design.¶

4.1.2.4. Composing with "Injected Headers" Header Protection

To compose a message using "Injected Headers" header protection, the composing MUA needs one additional input in addition to the Header Confidentiality Policy hcp defined in Section 4.1.2.2.¶

• legacy: a boolean value, indicating whether any recipient of the message is believed to have a legacy client. If all recipients are known to implement this draft, legacy should be set to false. (How a MUA determines the value of legacy is out of scope for this document; an initial implementation can simply set it to true)¶

The revised algorithm for applying cryptographic protection to a message is as follows:¶

• Create a new MIME leaf part legacydisplay with header Content-Type: text/plain; protected-headers="v1" and an empty body.¶

• if crypto contains encryption, and legacy is true:¶

  • For each header name and value (h,v) in origheaders:¶

    • If h is user-facing (see [I-D.autocrypt-lamps-protected-headers]):¶

      • If hcp(h,v) is not v:¶

        • Add h: v to the body of legacydisplay. For example, if h is Subject, and v is lunch plans?, then add the line Subject: lunch plans? to the body of legacydisplay¶

• If the body of legacydisplay is empty:¶

  • Let payload be MIME part origbody, discarding legacydisplay¶

• Else: (body of legacydisplay is not empty)¶

  • Construct a new MIME part wrapper with Content-Type: multipart/mixed¶
  • Give wrapper exactly two subparts: legacydisplay and origbody, in that order.¶
  • Let payload be MIME part wrapper¶

• For each header name and value (h,v) in origheaders:¶

  • Add header h of MIME part payload with value v¶
• Set the protected-headers parameter on the Content-Type of payload to v1¶
• Apply crypto to payload, producing MIME tree output¶

• If crypto contains encryption:¶

  • Create new empty list of header field names and values newh¶

  • For header name and value (h,v) in origheaders:¶

    • Let newval be hcp(h, v)¶

    • If newval is not null:¶

      • Add newh[h] to newval¶
  • Set origheaders to newh¶

• For each header name and value (h,v) in origheaders:¶

  • Add header h of output with value v¶
• Return output¶

Note that both new parameters (hcp and legacy) are effectively ignored if crypto does not contain encryption. This is by design, because they are irrelevant for signed-only cryptographic protections.¶

4.1.2.5. Choosing Between Wrapped Message and Injected Headers

When composing a message with end-to-end cryptographic protections, an MUA SHOULD protect the headers of that message as well as the body.¶

An MUA MAY protect the headers of any outbound message using either the "Wrapped Message" or the "Injected Headers" style of protection. See Section 4.2 for more discussion about reasons to choose one mechanism or another.¶

[[ TODO: this document should recommend generation of one particular scheme by default for new implementers ]]¶

4.1.3.1. Minimalist Header Confidentiality Policy

Accordingly, the most conservative recommended Header Confidentiality Policy only protects the Subject:¶

hcp_minimal(name, val_in) --> val_out: if name is 'Subject': return '[...]' else: return val_in ¶

4.1.3.2. Strong Header Confidentiality Policy

Alternately, a more aggressive (and therefore more privacy-preserving) Header Confidentiality Policy only leaks a handful of fields whose absence is known to increase rates of delivery failure, and simultaneously obscures the Message-ID behind a random new one:¶

hcp_strong(name, val_in) --> val_out: if name in ['From', 'To', 'Cc', 'Date']: return val_in else if name is 'Subject': return '[...]' else if name is 'Message-ID': return generate_new_message_id() else: return null ¶

The function generate_new_message_id() represents whatever process the MUA typically uses to generate a Message-ID for a new outbound message.¶

4.1.3.3. Offering Stronger Header Confidentiality

A MUA MAY offer even stronger confidentiality for headers of an encrypted message than described in Section 4.1.3.2. For example, it might implement an HCP that obfuscates the From field, or omits the Cc field, or ensures Date is represented in UTC (obscuring the local timezone).¶

The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶

4.1.4.1. Identifying that a Message has Protected Headers

An incoming message can be identified as having protected headers based on one of two signals:¶

• The Cryptographic Payload has Content-Type: message/rfc822 or Content-Type: message/global and the parameter forwarded has a value of no. See Section 4.1.4.3 for rendering guidance.¶
• The Cryptographic Payload has some other Content-Type and it has parameter protected-headers set to v1. See Section 4.1.4.4 for rendering guidance.¶

Messages of both types exist in the wild, and a sensible MUA should be able to handle them both. They provide the same semantics and the same meaning.¶

4.1.4.2. Updating the Cryptographic Summary

Regardless of whether a cryptographically-protected message has protected headers, the cryptographic summary of the message should be modified to indicate what protections the headers have.¶

Each header individually has exactly one the following protections:¶

• unprotected (this is the case for all headers in messages that have no protected headers)¶
• signed-only (bound into the same validated signature as the enclosing message, but also visible in transit)¶
• encrypted-only (only appears within the cryptographic payload; the corresponding external header was either omitted or obfuscated)¶
• encrypted-and-signed (same as encrypted, but additionally is under a validatd signature)¶

Note that while the message itself may be encrypted-and-signed, some headers may be replicated on the outside of the message (e.g. Date) Those headers would be signed-only, despite the message itself being encrypted-and-signed.¶

Rendering this information is likely to be complex and messy --- users may not understand it. It is beyond the scope of this document to suggest any specific graphical affordances or user experience. Future work should include examples of successful rendering of this information.¶

4.1.4.3. Rendering a Wrapped Message

When the Cryptographic Payload has Content-Type of message/rfc822 or message/global, and the parameter forwarded is set to no, the values of the protected headers are drawn from the headers of the Cryptographic Payload, and the body that is rendered is the body of the Cryptographic Payload.¶

A └─╴application/pkcs7-mime; smime-type="signed-data"
   ⇩ (unwraps to)
B  └┬╴message/rfc822 [Cryptographic Payload]
C   └┬╴multipart/alternative [Rendered Body]
D    ├─╴text/plain
E    └─╴text/html

C └┬╴multipart/alternative
D  ├─╴text/plain
E  └─╴text/html

F └─╴application/pkcs7-mime; smime-type="enveloped-data"
   ↧ (decrypts to)
G  └─╴application/pkcs7-mime; smime-type="signed-data"
    ⇩ (unwraps to)
H   └┬╴message/rfc822 [Cryptographic Payload]
I    └┬╴multipart/alternative [Rendered Body]
J     ├─╴text/plain
K     └─╴text/html

I └┬╴multipart/alternative
J  ├─╴text/plain
K  └─╴text/html

4.1.4.4. Rendering a Message with Injected Headers

When the Cryptographic Payload does not have a Content-Type of message/rfc822 or message/global, and the parameter protected-headers is set to v1, the values of the protected headers are drawn from the headers of the Cryptographic Payload, and the body that is rendered is the Cryptographic Payload itself.¶

L └─╴application/pkcs7-mime; smime-type="signed-data"
   ⇩ (unwraps to)
M  └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
N   ├─╴text/plain
O   └─╴text/html

M └┬╴multipart/alternative
N  ├─╴text/plain
O  └─╴text/html

P └─╴application/pkcs7-mime; smime-type="enveloped-data"
   ↧ (decrypts to)
Q  └─╴application/pkcs7-mime; smime-type="signed-data"
    ⇩ (unwraps to)
R   └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
S    ├─╴text/plain
T    └─╴text/html

R └┬╴multipart/alternative
S  ├─╴text/plain
T  └─╴text/html

U └─╴application/pkcs7-mime; smime-type="enveloped-data"
   ↧ (decrypts to)
V  └─╴application/pkcs7-mime; smime-type="signed-data"
    ⇩ (unwraps to)
W   └┬╴multipart/mixed [Cryptographic Payload]
X    ├─╴text/plain [Legacy Display]
Y    └┬╴multipart/alternative [Rendered Body]
Z     ├─╴text/plain
A'    └─╴text/html

Y └┬╴multipart/alternative
Z  ├─╴text/plain
A' └─╴text/html

4.1.4.5. Affordances for Debugging and Troubleshooting

Note that advanced users of an MUA may need access to the original message, for example to troubleshoot problems with the MUA itself, or problems with the SMTP transport path taken by the message.¶

A MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶

4.1.4.6. Composing a Reply to an Encrypted Message with Protected Headers

When composing a reply to an encrypted message with protected headers, the MUA is acting both as a receiving MUA and as a sending MUA. Special guidance applies here, as things can go wrong in at least two ways: leaking previously-confidential information, and replying to the wrong party.¶

4.1.4.7. Implicitly-rendered Header Fields

While From and To and Cc and Subject and Date are often explicitly rendered to the user, some header fields do affect message display, without being explicitly rendered.¶

For example, Message-Id, References, and In-Reply-To header fields may collectively be used to place a message in a "thread" or series of messages.¶

In another example, Section 4.1.4.6.2 observes that the value of the Reply-To field can influence the draft reply message. So while the user may never see the Reply-To header directly, it is implicitly "rendered" when the user interacts with the message by replying to it.¶

An MUA that depends on any implicitly-rendered header field in a message with protected headers SHOULD use the value from the protected header, and SHOULD NOT use any value found outside the cryptographic protection.¶

4.1.4.8. Unprotected Headers Added in Transit

Some headers are legitimately added in transit, and could not have been known to the sender at message composition time.¶

The most common of these headers are Received and DKIM-Signature, neither of which are typically rendered, either explicitly or implicitly.¶

If a receiving MUA has specific knowledge about a given header field, including that:¶

• the header field would not have been known to the original sender, and¶
• the header field might be rendered explicitly or implicitly,¶

then the MUA MAY decide to operate on the value of that header field from the unprotected header section, even though the message has protected headers.¶

The MUA MAY prefer to verify that the headers in question have additional transit-derived cryptographic protections (e.g., to test whether they are covered by a valid DKIM-Signature) before rendering or acting on them.¶

Specific examples appear below.¶

C.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory Hole")

An alternative option (based on the former autocrypt "Memory Hole" approach) to be considered, is described in [I-D.autocrypt-lamps-protected-headers].¶

Unlike the option described in Appendix C.1.1, this option does not use a "message/RFC822" wrapper to unambiguously delimit the Inner Message.¶

Before choosing this option, the following two issues must be assessed to ensure no interoperability issues result from it:¶

1. How current MIME parser implementations treat non-MIME Header Fields, which are not part of the outermost MIME entity and not part of a Message wrapped into a MIME entity of media type "message/rfc822", and how such Messages are rendered to the user.¶

   [I-D.autocrypt-lamps-protected-headers] provides some examples for testing this.¶

2. MIME-conformance, i.e. whether or not this option is (fully) MIME-conformant [RFC2045] ff., in particular also Section 5.1. of [RFC2046] on "Multipart Media Type). In the following an excerpt of paragraphs that may be relevant in this context:¶

      The only header fields that have defined meaning for body parts
      are those the names of which begin with "Content-".  All other
      header fields may be ignored in body parts.  Although they
      should generally be retained if at all possible, they may be
      discarded by gateways if necessary.  Such other fields are
      permitted to appear in body parts but must not be depended on.
      "X-" fields may be created for experimental or private
      purposes, with the recognition that the information they
      contain may be lost at some gateways.

      NOTE:  The distinction between an RFC 822 Message and a body
      part is subtle, but important.  A gateway between Internet and
      X.400 mail, for example, must be able to tell the difference
      between a body part that contains an image and a body part
      that contains an encapsulated Message, the body of which is a
      JPEG image.  In order to represent the latter, the body part
      must have "Content-Type: message/rfc822", and its body (after
      the blank line) must be the encapsulated Message, with its own
      "Content-Type: image/jpeg" header field.  The use of similar
      syntax facilitates the conversion of Messages to body parts,
      and vice versa, but the distinction between the two must be
      understood by implementors.  (For the special case in which
      parts actually are Messages, a "digest" subtype is also
      defined.)

The MIME structure of an Email Message looks as follows:¶

  <Outer Message Header Section (unprotected)>

  <Outer Message Body (protected)>

    <Inner Message Header Section>

    <Inner Message Body>

The following example demonstrates how an Original Message might be protected, i.e., the Original Message is contained as Inner Message in the Protected Body of an Outer Message. It illustrates the first Body part (of the Outer Message) as a "multipart/signed" (application/pkcs7-signature) media type:¶

Lines are prepended as follows:¶

• "O: " Outer Message Header Section¶
• "I: " Message Header Section¶

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.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=boundary-AM

     This is a multipart message in MIME format.
     --boundary-AM
  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@m.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.

     --boundary-AM
     Content-Transfer-Encoding: base64
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --boundary-AM--

The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the Inner Message (Header Section and Body).¶

The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section.¶

The Inner Message Body is the same as the Original Message Body.¶

The Original Message itself may contain any MIME structure.¶

C.1.2.1. Inner Message Header Fields

It is RECOMMENDED that the Inner Message contains all Header Fields of the Original Message with the exception of the following Header Field, which MUST NOT be included within the Inner Message nor within any other protected part of the Message:¶

• Bcc¶

[[ TODO: Bcc handling needs to be further specified (see also Appendix B.1). Certain MUAs cannot properly decrypt Messages with Bcc recipients. ]]¶

C.1.2.2. Wrapper

The wrapper is a simple MIME Header Section followed by an empty line preceding the Inner Message (inside the Outer Message Body). The media type of the wrapper MUST be "message/RFC822" and MUST contain the Content-Type header field parameter "forwarded=no" as defined in [I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously delimits the Inner Message from the rest of the Message.¶

C.1.2.3. Cryptographic Layers / Envelope

[[ TODO: Basically refer to S/MIME standards ]]¶

C.1.2.4. Sending Side Message Processing

For a protected Message the following steps are applied before a Message is handed over to the Submission Entity:¶

C.1.2.5. Outer Message Header Fields

* Subject: [...]

   MIME-Version: 1.0
   Content-Type: application/pkcs7-mime; smime-type=signed-data;
      name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m