juga
/
internet-drafts
forked from pEp.foundation/internet-drafts



Network Working Group                                       B. HoeneisenInternet-Draft                                            pEp FoundationIntended status: Informational                               A. MelnikovExpires: December 30, 2020                                     Isode Ltd                                                           June 28, 2020

                      Header Protection for S/MIME                 draft-ietf-lamps-header-protection-00
Abstract
   Privacy and security issues with email header protection in S/MIME   have been identified for some time.  However, the desire to fix these   issues has only recently been expressed in the IETF LAMPS Working   Group.  The existing S/MIME specification is to be updated regarding   header protection.
   This document describes the problem statement, generic use cases, and   the S/MIME specification for header protection.
Status of This Memo
   This Internet-Draft is submitted in full conformance with the   provisions of BCP 78 and BCP 79.
   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is at https://datatracker.ietf.org/drafts/current/.
   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on December 30, 2020.
Copyright Notice
   Copyright (c) 2020 IETF Trust and the persons identified as the   document authors.  All rights reserved.
   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (https://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect


Hoeneisen & Melnikov    Expires December 30, 2020               [Page 1]Internet-Draft          Header Protection S/MIME               June 2020

   to this document.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.
Table of Contents
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   4   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6     2.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   6     2.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   6     2.3.  Usability . . . . . . . . . . . . . . . . . . . . . . . .   6     2.4.  Interoperability  . . . . . . . . . . . . . . . . . . . .   6   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6     3.1.  Interactions  . . . . . . . . . . . . . . . . . . . . . .   7       3.1.1.  Main Case for Header Protection . . . . . . . . . . .   7       3.1.2.  Backward Compatibility  . . . . . . . . . . . . . . .   7     3.2.  Protection Levels . . . . . . . . . . . . . . . . . . . .   7   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   7     4.1.  Main Use Case . . . . . . . . . . . . . . . . . . . . . .   8       4.1.1.  MIME Format . . . . . . . . . . . . . . . . . . . . .   8       4.1.2.  Inner Message Header Fields . . . . . . . . . . . . .  13       4.1.3.  Wrapper . . . . . . . . . . . . . . . . . . . . . . .  13       4.1.4.  Outer Message Header Fields . . . . . . . . . . . . .  13       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   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  21   Appendix A.  Additional information . . . . . . . . . . . . . . .  21     A.1.  Stored Variants of Messages with Bcc  . . . . . . . . . .  21   Appendix B.  Document Changelog . . . . . . . . . . . . . . . . .  22   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  22   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23


Hoeneisen & Melnikov    Expires December 30, 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   of attacks on email, do not offer (full) end-to-end protection to the   header section and are not capable of providing privacy for the   information contained therein.
   The need for means of Data Minimization, which includes data   spareness and hiding all technically concealable information whenever   possible, has grown in importance over the past several years.
   A standard for end-to-end protection of the email header section   exists for S/MIME version 3.1 and later. (cf.  [RFC8551]):
      In order to protect outer, non-content-related message header      fields (for instance, the "Subject", "To", "From", and "Cc"      fields), the sending client MAY wrap a full MIME message in a      message/RFC822 wrapper in order to apply S/MIME security services      to these header fields.
   No mechanism for header protection (HP) has been standardized for   PGP/MIME (Pretty Good Privacy) [RFC3156] yet.
   Several varying implementations of end-to-end protections for email   header sections exist, though the total number of such   implementations appears to be rather low.
   Some LAMPS WG participants expressed the opinion that whatever   mechanism will be chosen, it should not be limited to S/MIME, but   also applicable to PGP/MIME.
   This document describes the problem statement (Section 2), generic   use cases (Section 3) and the specification for Header Protection   (Section 4).
   [I-D.ietf-lamps-header-protection-requirements] defines the   requirements that this specification is based on.
   This document is in early draft state and contains a proposal to base   the upcoming discussions on.  In any case, the final solution is to   be determined by the IETF LAMPS WG.


Hoeneisen & Melnikov    Expires December 30, 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:
   o  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A      form of active wiretapping attack in which the attacker intercepts      and selectively modifies communicated data to masquerade as one or      more of the entities involved in a communication association."
   o  S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.      [RFC8551])
   o  PGP/MIME: MIME Security with OpenPGP (cf.  [RFC3156])
   o  Message: An Email Message consisting of header fields      (collectively called "the Header Section of the message")      followed, optionally, by a Body; cf. [RFC5322].
   o  Transport: The entity taking care of the transport of a Message      towards the receiver or from the sender.  The Transport on the      sending side typically determines the destination recipients by      reading the To, Cc and Bcc Header Fields (of the Outer Message).      The Transport is typically implemented by an MTA (Mail Transfer      Agent).
   o  Header Field (HF): cf. [RFC5322] Header Fields are lines beginning      with a field name, followed by a colon (":"), followed by a field      body (value), and terminated by CRLF; cf. [RFC5322].
      Note: To avoid ambiguity, this document does not use the terms      "Header" or "Headers" in isolation, but instead always uses      "Header Field" to refer to the individual field and "Header      Section" to refer to the entire collection; cf. [RFC5322].
   o  Header Section (HS): The Header Section is a sequence of lines of      characters with special syntax as defined in [RFC5322].  It is the      (top) section of a message containing the Header Fields.
   o  Body: The Body is simply a sequence of characters that follows the      Header Section and is separated from the Header Section by an      empty line (i.e., a line with nothing preceding the CRLF); cf      [RFC5322].  It is the (bottom) section of Message containing the


Hoeneisen & Melnikov    Expires December 30, 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      to the MIME Header Fields of a Header Section that - in addition      to MIME Header Fields - also contains non-MIME Header Fields.
   o  Header Protection (HP): cryptographic protection of email Header      Sections (or parts of it) for signatures and/or encryption
   o  Protection Levels (PL): One of 'signature and encryption',      'signature only' or 'encryption only' (cf.  Section 3.2)
   o  Original Message (OrigM): The message to be protected before any      protection related processing has been applied on the sending      side.
   o  Inner Message (InnerM): The message to be protected, i.e. which      wrapping and protection measures are applied to on the sending      side or the result of decryption and unwrapping on the receiving      side respectively.  Typically, the Inner Message is in clear text.      The Inner Message is a subset of (or the same as) the Original      Message (cf.  Section 4.1.2).  The Inner Message must be the same      on the sending and the receiving side.
   o  Outer Message (OuterM): The Message as handed over to the      Transport or received from the Transport respectively.  The Outer      Message normally differs on the sending and the receiving side      (e.g. new Header Fields are added by intermediary nodes).
   o  Receiving User Facing Message (RUFM): The message used for      rendering at the receiving side after the Outer Message Header      Section has been merged with the Inner Message Header Section.
   o  Essential Header Fields (EHF): The minimum set of Header Fields an      Outer Message Header Section SHOULD contain; cf. Section 4.1.4.
   o  Protected: Protected refers to the parts of a message where      protection measures of any Protection Level have been applied to.
   o  Protected Message: A message that protection measures of any      Protection Levels have been applied to.


Hoeneisen & Melnikov    Expires December 30, 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 of all technically      concealable information whenever possible.
2.  Problem Statement
   The LAMPS charter contains the following Work Item:
      Update the specification for the cryptographic protection of email      headers - both for signatures and encryption - to improve the      implementation situation with respect to privacy, security,      usability and interoperability in cryptographically-protected      electronic mail.  Most current implementations of      cryptographically-protected electronic mail protect only the body      of the message, which leaves significant room for attacks against      otherwise-protected messages.
   In the following a set of challenges to be addressed:
   [[ TODO: enhance this section, add more items to the following ]]
2.1.  Privacy
   o  Data Minimization, which includes data spareness and hiding all      technically concealable information whenever possible
2.2.  Security
   o  MITM attacks (cf.  [RFC4949])
2.3.  Usability
   o  User interaction / User experience
2.4.  Interoperability
   o  Interoperability with [RFC8551] implementations
3.  Use Cases
   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).


Hoeneisen & Melnikov    Expires December 30, 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
   Both peers (sending and receiving side) fully support Header   Protection as specified in this document or the receiving side is at   least compliant with the MIME specification [RFC2045], ff.; cf.   Section 4.1.
3.1.2.  Backward Compatibility
   The sending side fully supports Header protection as specified in   this document, while the receiving side does not support the MIME   specification [RFC2045], ff. correctly; see Section 4.2.
   Note: The compatibility of legacy HP systems with this new solutions,   and how to handle issues surrounding future maintenance for these   legacy systems, will be decided by the LAMPS WG.
3.2.  Protection Levels
   The following protection levels need to be considered:
   a) Signature and encryption
   Messages containing a cryptographic signature, which are also   encrypted.
   b) Signature only
   Messages containing a cryptographic signature, but which are not   encrypted.
   c) Encryption only
   Messages that are encrypted, but do not contain a cryptographic   signature.
4.  Specification
   This section contains the specification for Header Protection in   S/MIME to update and clarifies Section 3.1 of [RFC8551] (S/MIME 4.0).   This specification is likely to be integrated into S/MIME at some   later stage.


Hoeneisen & Melnikov    Expires December 30, 2020               [Page 7]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):
   Sending and receiving sides SHOULD implement "signature and   encryption", which is the default to use on the sending side.
   Certain implementations MAY decide to send "signature only" messages,   depending on the circumstances and customer requirements.  Sending   side MAY and receiving sides SHOULD implement "signature only".
   It generally is NOT RECOMMENDED to send a message with protection   level "encryption only".  On the other hand, messages with protection   level "encryption only" might arrive at the receiving side.  While   not targeted to protection level "encryption only", this   specification is assumed to also function for "encryption only".   Receiving sides SHOULD implement "encryption only".
   Note: It is for further study whether or not more guidance for   handling messages with protection level "encryption only" at the   receiving side is needed.
4.1.  Main Use Case
   This section applies to the Interaction (cf.  Section 3.1), where all   involved parties (sending and receiving side) implement this   specification or the receiving side is at least compliant with the   MIME specification [RFC2045], ff.  (For backward compatibility cases   cf. Section 4.2).
4.1.1.  MIME Format
   Currently there are two options in discussion:
   1.  The option according to the current S/MIME specification (cf.       [RFC8551])
   2.  An alternative option that is based on the former "memory hole"       approach (cf.  [I-D.autocrypt-lamps-protected-headers])
4.1.1.1.  S/MIME Specification
   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.


Hoeneisen & Melnikov    Expires December 30, 2020               [Page 8]Internet-Draft          Header Protection S/MIME               June 2020

   To help the receiving side to distinguish between forwarded and   wrapped message, a Content-Type header field parameter "forwarded" is   added as defined in [I-D.melnikov-iana-reg-forwarded].  Certain   mailing applications might display the Inner Message as attachment   otherwise.
   The MIME structure of 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 header section and payload of   a protected body part might look like.  For example, this will be the   first body part of a multipart/signed message or the signed and/or   encrypted payload of the application/pkcs7-mime body part.  Lines   prepended by "O: " are the Outer Message Header Section.  Lines   prepended by "I: " are the Inner Message Header Section.  Lines   prepended by "W: " are the wrapper (MIME Header Section):


Hoeneisen & Melnikov    Expires December 30, 2020               [Page 9]Internet-Draft          Header Protection S/MIME               June 2020

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.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=.cbe16d2a-e1a3-4220-b821-38348fc97237
     This is a multipart message in MIME format.     --.cbe16d2a-e1a3-4220-b821-38348fc97237  W: Content-Type: message/RFC822; forwarded=no  W:  I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)  I: From: "Alexey Melnikov" <alexey.melnikov@example.net>  I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>  I: MIME-Version: 1.0  I: MMHS-Primary-Precedence: 3  I: Subject: Meeting at my place  I: To: somebody@example.net  I: X-Mailer: Isode Harrier Web Server  I: Content-Type: text/plain; charset=us-ascii
     This is an important message that I don't want to be modified.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237     Content-Transfer-Encoding: base64     Content-Type: application/pkcs7-signature
     [[base-64 encoded signature]]
     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

   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.
   The Inner Message Header Section is the same as (or a subset of) the   Original Message Header Section (cf.  Section 4.1.2).
   The Inner Message Body is the same as the Original Message Body.


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 10]Internet-Draft          Header Protection S/MIME               June 2020

   The Original Message itself may contain any MIME structure.
   There may also be an additional MIME layer with media type   "multipart/mixed" in the Outer Message Body to contain the Inner   Message (wrapped in a "message/RFC822") along with other MIME   part(s).
4.1.1.2.  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 Section 4.1.1.1, this option does not   use a "message/RFC822" wrapper to unambigously delimit the Inner   Message.
   Note: it is for further study, whether or not this option is (fully)   compliant with the MIME standard, in particuar also [RFC2046],   Section 5.1.  (Multipart Media Type).
   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 header section and payload of   a protect body part might look like.  For example, this will be the   first body part of a multipart/signed message or the signed and/or   encrypted payload of the application/pkcs7-mime body part.  Lines   prepended by "O: " are the outer header section.  Lines prepended by   "I: " are the inner header section.


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 11]Internet-Draft          Header Protection S/MIME               June 2020

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>  O: Subject: Meeting at my place  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>  O: MIME-Version: 1.0  O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;  O:  protocol="application/pkcs7-signature";  O:  boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
     This is a multipart message in MIME format.     --.cbe16d2a-e1a3-4220-b821-38348fc97237  I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)  I: From: "Alexey Melnikov" <alexey.melnikov@example.net>  I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>  I: MIME-Version: 1.0  I: MMHS-Primary-Precedence: 3  I: Subject: Meeting at my place  I: To: somebody@example.net  I: X-Mailer: Isode Harrier Web Server  I: Content-Type: text/plain; charset=us-ascii
     This is an important message that I don't want to be modified.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237     Content-Transfer-Encoding: base64     Content-Type: application/pkcs7-signature
     [[base-64 encoded signature]]
     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

   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 (cf.  Section 4.1.2).
   The Inner Message Body is the same as the Original Message Body.
   The Original Message itself may contain any MIME structure.
   There may also be an additional MIME layer with media type   "multipart/mixed" in the Outer Message Body to contain the Inner   Message along with other MIME part(s).


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 12]Internet-Draft          Header Protection S/MIME               June 2020

4.1.2.  Inner Message Header Fields
   It is RECOMMEND that the Inner Messages contains all the Header   Fields of the Original Message with the exception of the following   Header Field, which MUST NOT be included to the Inner Message nor to   any other protected part of the message:
   o  Bcc
   [[ TODO: Bcc handling needs to be further specified (see also   Appendix A.1).  Certain MUAs cannot properly decrypt messages with   Bcc recipients. ]]
4.1.3.  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 SHOULD contain   the Content-Type header field parameter "forwarded=no" as defined in   [I-D.melnikov-iana-reg-forwarded].  The wrapper delimits unambigously   the Inner Message from the rest of the message.
4.1.4.  Outer Message Header Fields
   To maximize Privacy, it is strongly RECOMMENDED to follow the   principle of Data Minimization (cf.  Section 2.1).
   However, the Outer Message Header Section SHOULD contain the   Essential Header Fields and, in addition, MUST contain the Header   Fields of the MIME Header Section part to describe the encryption or   signature as per [RFC8551].
   The following Header Fields are defined as the Essential Header   Fields:
   o  From
   o  To (if present in the OrigM)
   o  Cc (if present in the OrigM)
   o  Bcc (if present in the OrigM, see also Section 4.1.2 and      Appendix A.1)
   o  Date
   o  Message-ID


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 13]Internet-Draft          Header Protection S/MIME               June 2020

   o  Subject
   Some of these Header Fields are needed by the Transport (e.g. to   determine the destination).  Furthermore, not including certain   Header Fields may trigger spam detection to flag the message as spam   and/or lead to user experience (UX) issues.
   For further Data Minimization the value of the Subject Header Field   SHOULD be obfuscated.  In addition, the value of other Essential   Header Fields MAY be obfuscated.  Further Header Fields MAY be   obfuscated, though simply not adding those to the Outer Message   Header SHOULD be prefered over obfuscation.  Header Field obfuscation   is further specified in Section 4.1.4.1.  Header Fields not   obfuscated SHOULD contain the same values as in the Original Message.
   The MIME Header Section part is the collection of MIME Header Fields   describing the following MIME structure as defined in [RFC2045].  A   MIME Header Section part typically includes the following Header   Fields:
   o  MIME-Version
   o  Content-Type
   o  Content-Transfer-Encoding
   o  Content-Disposition
   The following example shows the MIME header of an S/MIME signed   message (using application/pkcs7-mime with SignedData):
      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

   Depending on the scenario, further Header Fields MAY be exposed in   the Outer Message Header Section, which is NOT RECOMMENDED unless   justified.  Such Header Fields may include e.g.:
   o  References
   o  Reply-To
   o  In-Reply-To


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 14]Internet-Draft          Header Protection S/MIME               June 2020

4.1.4.1.  Obfuscation of Outer Message Header Fields
   If the values of the following Outer Message Header Fields are   obfuscated, those SHOULD assume the following values:
   * Subject: ...   * Message-ID: <new randomly generated Message-ID>   * Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
   [[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the   same week. ]]
   In certain implementations also the From, To, and/or Cc Header Field   MAY be obfucated.  Those may be replaced by e.g.
   o  To: Obfuscated anonymous@anonymous.invalid [1]
   Such implementations need to ensure that the Transport has access to   these Header Fields in clear text and is capable of processing those.
   A use case for obfuscation of all Outer Message Header Fields is   mixnet netwerks, i.e. "onion routing" for email (e.g.[pEp.mixnet]).
   Note: It is for further study to what extent Header Field obfuscation   (adversely) impacts spam filtering.
4.1.5.  Receiving User Facing Message Header Fields
   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.
   [[ TODO: Do we need to take special care for HFs, which may appear   multiple times, e.g.  Received HF? ]]
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>                             From (OrigM)      = From                             To (OrigM)        = To                             Cc (OrigM)        = Cc                             Bcc (OrigM)       = Bcc*       > Bcc                             Date (OrigM)      = Date                             Message-ID (OrigM)= Message-ID                             Subject (new)     = Subject                             <MIME-HSp> (new)  = <MIME-HSp>
                             PROTECTED:          PROTECTED:                             <Wrapper> (new)   = <Wrapper>   From       > From       > From              = From       > From   To         > To         > To                = To         > To   Cc*        > Cc         > Cc                = Cc         > Cc   Bcc*   Date       > Date       > Date              = Date       > Date   Message-ID > Message-ID > Message-ID        = Message-ID > Message-ID   Subject    > Subject    > Subject           = Subject    > Subject   <More HF>  > <More HF>  > <More HF>         = <More HF>  > <More-HF>   <MIME-HSp> > <MIME-HSp> > <MIME-HSp>        = <MIME-HSp> > <MIME-HSp>   <Body>     > <Body>     > <Body>            = <Body>     > <Body>                             <Signature>* (new)= <Signature>

   Legend:
   o  OuterM(S): Outer Message (OuterM) at sending side (before      processing by Transport)
   o  OuterM(R): Outer Message at receiving side (as received by      Transport)
   o  InnerM: Inner Message (that protection is applied to)
   o  RUFM: Receiving User Facing Message
   o  More-HF: Additional Header Fields (HF) in the Original Message      (OrigM)
   o  Wrapper: MIME Header Section; with media type (message/RFC822) to      unambigously delimit the inner message from the rest of the      message.
   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)
   o  >: taken over / copied from last column
   o  =: propagates unchanged, unless something unusual (e.g. attack)      happens
   o  *: 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.
   o  (new) / (OrigM): HF or MIME-HSp is generated depending on the      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   achieve backward compatibility with existing S/MIME (and PGP/MIME)   implementations unaware of this specification (Legacy Display).  It   mainly focuses on email clients that do not render emails using   header protection (nicely) and may confuse the user.  While this has   been observed occasionally in PGP/MIME (cf.  [RFC3156]), the extent   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


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).
5.  Security Considerations
   [[ TODO ]]
6.  Privacy Considerations
   [[ TODO ]]
7.  IANA Considerations
   This document requests no action from IANA.
   [[ RFC Editor: This section may be removed before publication. ]]
8.  Acknowledgments
   The authors would like to thank the following people who have   provided helpful comments and suggestions for this document: Claudio   Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,   Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei   Chuang.
9.  References
9.1.  Normative References
   [I-D.ietf-lamps-header-protection-requirements]              Melnikov, A. and B. Hoeneisen, "Problem Statement and              Requirements for Header Protection", draft-ietf-lamps-              header-protection-requirements-01 (work in progress),              October 2019.
   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail              Extensions (MIME) Part One: Format of Internet Message              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,              <https://www.rfc-editor.org/info/rfc2045>.


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,              <https://www.rfc-editor.org/info/rfc2119>.
   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,              DOI 10.17487/RFC5322, October 2008,              <https://www.rfc-editor.org/info/rfc5322>.
   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0              Message Specification", RFC 8551, DOI 10.17487/RFC8551,              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
9.2.  Informative References
   [I-D.autocrypt-lamps-protected-headers]              Einarsson, B., juga, j., and D. Gillmor, "Protected              Headers for Cryptographic E-mail", draft-autocrypt-lamps-              protected-headers-02 (work in progress), December 2019.
   [I-D.melnikov-iana-reg-forwarded]              Melnikov, A. and B. Hoeneisen, "IANA Registration of              Content-Type Header Field Parameter 'forwarded'", draft-              melnikov-iana-reg-forwarded-00 (work in progress),              November 2019.
   [I-D.pep-email]              Marques, H., "pretty Easy privacy (pEp): Email Formats and              Protocols", draft-marques-pep-email-02 (work in progress),              October 2018.
   [pEp.mixnet]              pEp Foundation, "Mixnet", June 2020,              <https://dev.pep.foundation/Mixnet>.
   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,              "MIME Security with OpenPGP", RFC 3156,              DOI 10.17487/RFC3156, August 2001,              <https://www.rfc-editor.org/info/rfc3156>.


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,              <https://www.rfc-editor.org/info/rfc6376>.
   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for              Authorizing Use of Domains in Email, Version 1", RFC 7208,              DOI 10.17487/RFC7208, April 2014,              <https://www.rfc-editor.org/info/rfc7208>.
   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based              Message Authentication, Reporting, and Conformance              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,              <https://www.rfc-editor.org/info/rfc7489>.
9.3.  URIs
   [1] mailto:anonymous@anonymous.invalid
Appendix A.  Additional information
A.1.  Stored Variants of Messages with Bcc
   Messages containing at least one recipient address in the Bcc header   field may appear in up to three different variants:
   1.  The message for the recipient addresses listed in To or Cc header       fields, which must not include the Bcc header field neither for       signature calculation nor for encryption.
   2.  The message(s) sent to the recipient addresses in the Bcc header       field, which depends on the implementation:
       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
       b) The same message for each recipient in the Bcc header field       with a Bcc header field containing an indication such as       "Undisclosed recipients" (but no addressees)
       c) The same message for each recipient in the Bcc header field       which does not include a Bcc header field (this message is       identical to 1. / cf. above)


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   depending on the recipient.
Appendix B.  Document Changelog
   [[ RFC Editor: This section is to be removed before publication ]]
   o  draft-ietf-lamps-header-protection-00
      *  Initial version (text partialy taken over from         [I-D.ietf-lamps-header-protection-requirements]
Appendix C.  Open Issues
   [[ RFC Editor: This section should be empty and is to be removed   before publication. ]]
   o  Ensure "protected header" (Ex-Memory-Hole) option is (fully)      compliant with the MIME standard, in particuar also [RFC2046],      Section 5.1.  (Multipart Media Type) Section 4.1.1.2.
   o  Decide on format of obfuscated HFs, in particular Date HF      (Section 4.1.4.1)
   o  Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
   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.8.2)
   o  Do we need to take special care of HFs that may appear multiple      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)?
   o  Decide on whether or not merge requirements from      [I-D.ietf-lamps-header-protection-requirements] into this      document.


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
   o  Improve definitions in Section 3.2
   o  Privacy Considerations Section 6
   o  Security Considerations Section 5
Authors' Addresses
   Bernie Hoeneisen   pEp Foundation   Oberer Graben 4   CH-8400 Winterthur   Switzerland
   Email: bernie.hoeneisen@pep.foundation   URI:   https://pep.foundation/

   Alexey Melnikov   Isode Ltd   14 Castle Mews   Hampton, Middlesex  TW12 2NP   UK
   Email: alexey.melnikov@isode.com


Hoeneisen & Melnikov    Expires December 30, 2020              [Page 23]