Network Working Group C. Luck Internet-Draft pEp Foundation Intended status: Informational B. Hoeneisen Expires: September 9, 2019 Ucom.ch March 08, 2019 pretty Easy privacy (pEp): Header Protection draft-luck-lamps-pep-header-protection-00 Abstract Issues with email header protection in S/MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed. The pretty Easy privacy (pEp) implementations currently use a mechanism quite similar to the currently standardized message wrapping for S/MIME. The main difference is that pEp is using PGP/ MIME instead. In LAMPS also voices have been expressed, that whatever mechanism will be choosen, it should not be limited to S/MIME, but also applied to PGP/MIME. This document aims to contribute to this discussion and share pEp implementation experience with email 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 September 9, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Luck & Hoeneisen Expires September 9, 2019 [Page 1] Internet-Draft pEp Header Protection March 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4 2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 7 4.2. Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection . . . . . . . 7 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8 4.3. Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported) . . . . . 8 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8 5. Message Format for Header Protection . . . . . . . . . . . . 8 5.1. Preparing a Message for Header Protection . . . . . . . . 11 5.1.1. Requirements for the Original Message . . . . . . . . 12 5.1.2. Building the Inner Message . . . . . . . . . . . . . 12 5.1.3. Building the Outer Message for Signed Inner Messages 14 5.1.4. Building the Outer Message for Signed and Encrypted Inner Messages . . . . . . . . . . . . . . . . . . . 15 5.1.5. S/MIME Compatibility . . . . . . . . . . . . . . . . 16 6. Candidate Header Fields for Header Protection . . . . . . . . 16 7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 16 8. Processing Incoming Email with Protected Headers . . . . . . 17 8.1. Detecting Header Protection in Incoming Email . . . . . . 17 8.2. Resolving Conflicting Protected and Unprotected Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. Processing of Signed-only Email . . . . . . . . . . . . . 18 8.4. Incoming Filter Processing . . . . . . . . . . . . . . . 18 8.4.1. Staged Filtering of Inbound Messages . . . . . . . . 19 Luck & Hoeneisen Expires September 9, 2019 [Page 2] Internet-Draft pEp Header Protection March 2019 8.5. Outgoing Filter Processing . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Current software implementing pEp . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 23 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction A range of protocols for the protection of electronic mail (email) exist, which allow to assess the authenticity and integrity of the email headers section or selected header fields 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 end-to-end protection to the headers section and are not capable of providing privacy for the information contained therein. Also the need for means of Data Minimization, which includes data spareness and hiding of all information, which technically can be hidden, has grown in importance over the past years. End-to-end protection for the email headers section or header fields (HF) is currently not widely implemented - neither for messages protected by means of S/MIME nor for PGP (Pretty Good Privacy) nor any other form. A standard exists for S/MIME since version 3.1. (cf. [RFC5751] and [I-D.ietf-lamps-rfc5751-bis]): 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 has been standardized for PGP/MIME yet. At least two variants of header protection are known to be implemented. A recently submitted Internet-Draft [I-D.melnikov-lamps-header-protection] discusses the two variants and Luck & Hoeneisen Expires September 9, 2019 [Page 3] Internet-Draft pEp Header Protection March 2019 the challenges with header protection for S/MIME. The two variants are referred to as: o Option 1: Memory Hole o Option 2: Wrapping with message/rfc822 or message/global pEp (pretty Easy privacy) [I-D.birk-pep] for email [I-D.marques-pep-email] already implements an option quite similar to Option 2, adapting the S/MIME standards to PGP/MIME. Existing implementations of pEp have also added inbound support for "Memory Hole" referred to above as Option 1. On par with other implementations of "Memory Hole" support for it is currently limited to the "Subject" header field only. Interoperability and implementation symmetry between PGP/MIME and S/MIME is planned by pEp, but still in an early stage of development. This document lists generic use cases and requirements for header protection and describes the header protection implemented in "pEp message format version 2", and how non-pEp mail clients may implement header protection independently from other pEp standards. 2. Terms 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]. 2.1. The OpenPGP Radix-64 In the examples following in this section, it is a common pattern to have a MIME encoded mail containing ("wrapping") another signed and eventually encrypted mail. Such enclosed mails are encoded following the OpenPGP standard, which specifies an encoding called "Radix-64", which is 7-bit transport-encoding compatible by design. The Radix-64 consists of a begin and an end Armor Header Line, a stream of base64-encoded data limited to 78 characters per line plus , and an encoded CRC-24 value. The following is an example, with some similar lines of base64 output replaced with ellipsis: Luck & Hoeneisen Expires September 9, 2019 [Page 4] Internet-Draft pEp Header Protection March 2019 -----BEGIN PGP MESSAGE----- hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv ... j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt Xd9bdvHx/ReenAk/ =7WaL -----END PGP MESSAGE----- To make the examples look more compact and relevant, the above will be replaced symbolically by: [[----- OpenPGP Radix-64 Block -----]] 2.1.1. Radix-64 in the Context of MIME Messages Note that OpenPGP and MIME specifications overlap when a Radix-64 immediately precedes a MIME boundary. The sequence immediately preceding a MIME boundary delimiter line is considered to be part of the delimiter in [RFC2046], 5.1. And in OpenPGP, line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit in [RFC4880], 6.2. Keeping an empty line between the end Armor Header Line and the MIME boundary line is suggested. 3. Use Cases In the following, we show the generic use cases that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used for which Header Protection (HP) is to be applied to. 3.1. Interactions The main interaction case for HP is: 1) Both peers (sending and receiving side) fully support HP For backward compatibility of legacy clients - unaware of any HP - the following intermediate interactions need to be considered as well: Luck & Hoeneisen Expires September 9, 2019 [Page 5] Internet-Draft pEp Header Protection March 2019 2) The sending side fully supports HP, while the receiving side does not support any HP 3) The sending side does not support any HP, while the receiving side fully supports HP (trivial case) 4) Neither the sending side nor the receiving side supports any HP (trivial case) The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S/MIME since version 3.1 (cf. [RFC5751] and [I-D.ietf-lamps-rfc5751-bis]), in the following designated as legacy HP: 5) The sending side fully supports HP, while the receiving side supports legacy HP only 6) The sending side supports legacy HP only, while the receiving side fully supports HP 7) Both peers (sending and receiving side) support legacy HP only 8) The sending side supports legacy HP only, while the receiving side does not support any HP 9) The sending side does not support any HP, while the receiving side supports legacy HP only (trivial case) Note: It is to be decided whether to ensure legacy HP systems do not conflict with any new solution for HP at all or whether (and to which degree) backward compatibility to legacy HP systems shall be maintained. 3.2. Protection Levels The following protection levels need to be considered: a) signature and encryption b) signature only c) encryption only [[ TODO: verify whether relevant ]] Luck & Hoeneisen Expires September 9, 2019 [Page 6] Internet-Draft pEp Header Protection March 2019 4. Requirements In the following a list of requirements that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used to apply HP to. 4.1. General Requirements This subsection is listing the requirements to address use case 1) (cf. Section 3.1). G1: Define the format for HP for all protection levels. This includes MIME structure, Content-Type (including charset and name), Content-Disposition (including filename), and Content-Transfer-Encoding. Furthermore, it must be defined, how a public key should be included. 4.1.1. Sending Side GS1: Define which HF (Header Fields) should or must be protected for all protection levels. GS2: Define which HF should or must appear in clear-text of an encrypted email. GS3: Define which HF should or must not appear in clear-text of an encrypted email. 4.1.2. Receiving Side GR1: Define which HF are displayed to the user in case of conflicting information between the protected and unprotected headers. 4.2. Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection This sub-section addresses the use cases 2) - 4) (cf. Section 3.1) B1: Depending on the solution, define a means to distinguish between forwarded messages and encapsulated messages using new HP mechanism. Luck & Hoeneisen Expires September 9, 2019 [Page 7] Internet-Draft pEp Header Protection March 2019 4.2.1. Sending side BS1: Define how full HP support can be indicated to outgoing messages. BS2: Define how full HP support of the receiver can be detected or guessed 4.2.2. Receiving side BR1: Define how full HP support can be detected in incoming messages. 4.3. Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported) This sub-section addresses the use cases 5) - 9) (cf. Section 3.1). LS1: Depending on the solution, define a means to distinguish between forwarded messages, legacy S/MIME encapsulated messages, and encapsulated messages using new HP mechanism. 4.3.1. Sending Side LSS1: Define how legacy HP support can be indicated to outgoing messages. LSS2: Define how legacy HP support of the receiver can be detected or guessed. 4.3.2. Receiving Side LSR1: Define how legacy HP support can be detected in incoming messages. 5. Message Format for Header Protection The pEp message format version 2 is designed such that a receiving Mail User Agent (MUA), which is OpenPGP-compliant but not pEp- compliant - and which is not implementing header protection either -, still has built-in capability to properly decode the mail and display all information to the user. Luck & Hoeneisen Expires September 9, 2019 [Page 8] Internet-Draft pEp Header Protection March 2019 No standard is currently available which enables MUAs to reliably determine whenever a nested message/rfc822 entity is meant to override the containing message, or if it was effectively forwarded. pEp currently intends to implement the proposal described by [I-D.melnikov-lamps-header-protection], 3.2, which defines a new Content-Type header field parameter with name "forwarded", for the MUA to distinguish between a forwarded message and a nested message for the purpose of header protection, i.e., using "forwarded=no". Header protecton provides both integrity and confidentiality. Confidentiality requires the same effective key distribution mechanism to be in-place as for integrity, such that when integrity can be achieved, also can confidentiality. Integrity and confidentiality SHOULD always be used together. The pEp message format version 2 (as used by all the various pEp implementations, cf. Section 10) is similar to what is standardized for S/MIME in [RFC5751] and its successor [I-D.ietf-lamps-rfc5751-bis]: In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, [...]. With pEp message format version 2, the original full MIME message is also wrapped in a message/rfc822 wrapper, but this entity is in turn wrapped in a multipart/mixed entity. The purpose of the additional nesting is to allow for public keys of the sender to be stored alongside the original message while being protected by the same mechanism. Thus, the top-level entity contains o exactly one entity of type message/rfc822, and o at most one entity of type application/pgp-keys The current pEp message format version 2.0 also adds one entity of type text/plain where the body part reads "pEp-Wrapped-Message-Info: OUTER". It is currently being discussed if this information should be migrated to the headers section of the top-level entity; Luck & Hoeneisen Expires September 9, 2019 [Page 9] Internet-Draft pEp Header Protection March 2019 such an upgrade would be part of the the pEp message format version 2.1. A pEp message MUST have a text/plain element. The original plaintext message is prepended by the string "pEp-Wrapped-Message-Info: INNER". Also this header may be moved into the headers section of the entity in message format version 2.1. [[ TODO: The pEp-Wrapped-Message-Info information is probably not needed for header protection. ]] This is an example of the top-level MIME entity, before being encrypted and signed: Luck & Hoeneisen Expires September 9, 2019 [Page 10] Internet-Draft pEp Header Protection March 2019 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6b8b4567327b23c6643c986966334873" --6b8b4567327b23c6643c986966334873 Content-Type: text/plain; charset="utf-8"; name="msg.txt" Content-Disposition: inline; filename="msg.txt" pEp-Wrapped-Message-Info: OUTER --6b8b4567327b23c6643c986966334873 Content-Type: message/rfc822; forwarded="no" From: John Doe To: Mary Smith Subject: Example Date: Fri, 30 Jun 2018 09:55:06 +0200 Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy> X-Pep-Version: 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; name="msg.txt" Content-Disposition: inline; filename="msg.txt" Content-Transfer-Encoding: quoted-printable pEp-Wrapped-Message-Info: INNER p=E2=89=A1p for Privacy by Default. --6b8b4567327b23c6643c986966334873 Content-Type: application/pgp-keys Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK----- --6b8b4567327b23c6643c986966334873-- 5.1. Preparing a Message for Header Protection Header protection requires an ideal "original message" to be transformed into an "inner message", which must be signed and preferably encrypted according to MIME Security with OpenPGP [RFC3156], resulting in an "outer message" (not to be confused with the "inner" and "outer" labels in the above mentioned pEp-Wrapped- Luck & Hoeneisen Expires September 9, 2019 [Page 11] Internet-Draft pEp Header Protection March 2019 Message-Info header field). The resulting "outer message" requires some additional adjustments so that the protected message is properly handled on all Mail User Agents. Note that pEp email clients are REQUIRED to sign and encrypt the message as per [I-D.marques-pep-email], while non-pEp clients MAY encrypt messages. 5.1.1. Requirements for the Original Message The original message MUST be structured as a valid [RFC5322] message with a header and a body. Additionally, the body of the original message MUST be structured in body parts according to the MIME standard [RFC2046]. The primary entity of type text/plain which is implicitly or explicitly intended for inline display SHOULD be noted (the "message entity"). The selection MUST adhere to MIME standards regarding precedence of parts in multipart structures. [[ TODO: It is currently undefined how to proceed if no such message entity exists. ]] 5.1.2. Building the Inner Message The original message entity is to be substituted with a text/plain part (and the headers and parameters as specified later), which in turn will contain a valid [RFC5322] message, where: o the message SHOULD NOT be structured in MIME parts, o the body replicates the body of the substituee message entity decoded according to its eventual Content-Transfer-Encoding header field value, o the Content-Type header field is set to "text/plain" * and the "charset" parameter is set to "UTF-8" * and the "name" parameter is set to "msg.txt" * and no other parameter is set on the Content-Type header field, o the Content-Disposition is set to "inline" * and the "filename" parameter is set to "msg.txt" Luck & Hoeneisen Expires September 9, 2019 [Page 12] Internet-Draft pEp Header Protection March 2019 * and no other parameter is set on the Content-Disposition header field. The new body of the message-body (which now contains a valid [RFC5322] message) must be re-applied a Content-Transfer-Encoding such that: o if the message is to be signed and encrypted, the substituted message-body part results in a valid UTF-8 string not containing UTF-8 null symbols, o if the message is to be signed but not encrypted, the substituted message entity is 7-bit transport-safe. The Content-Transfer-Encoding previously in place on the substitutee message-body SHOULD be preferred for the substitued message-body whenever it is not to be excluded by other criterias. The inner message is then to be produced such that it can be represented as a string which consists of only valid UTF-8 symbols and additionally such that it does not eventually contain the UTF-8 null symbol. No other Content-Transfer-Encoding other than "7bit", "8bit", or "binary" is permitted for the root part of the inner message. The headers section, the MIME boundaries and the headers sections of the body parts MUST be limited to valid UTF-8 symbols and no UTF-8 null symbol. Body parts and sub-parts which do not represent a valid UTF-8 string or MAY include a UTF-8 null symbol, MUST be applied an appropriate Content-Transfer-Encoding to make their encoded representation valid in UTF-8 (e.g., with "quoted-printable" or "base64"). The following shows an example original message and the resulting message/rfc822 entity for inclusion in the outer multipart/mixed. From: John Doe To: Mary Smith Subject: Example Date: Fri, 30 Jun 2018 09:55:06 +0200 Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable p=E2=89=A1p for Privacy by Default. Luck & Hoeneisen Expires September 9, 2019 [Page 13] Internet-Draft pEp Header Protection March 2019 MIME-Version: 1.0 Content-Type: message/rfc822; forwarded="no" From: John Doe To: Mary Smith Subject: Example Date: Fri, 30 Jun 2018 09:55:06 +0200 Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy> X-pEp-Version: 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; name="msg.txt" Content-Disposition: inline; filename="msg.txt" Content-Transfer-Encoding: quoted-printable pEp-Wrapped-Message-Info: INNER p=E2=89=A1p for Privacy by Default. The protected message has the following structure. + message/rfc822; forwarded="no"; [ { all protected headers, overridden by: Message-ID: X-pEp-Version: 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; name="msg.txt" Content-Disposition: inline; filename="msg.txt" Content-Transfer-Encoding: ... } [ pEp-Wrapped-Message-Info: INNER (content-transfer-encoded) [ original body ] ] ] + application/pgp-keys (optional) 5.1.3. Building the Outer Message for Signed Inner Messages The outer message is an email with a body part of type multipart/ signed or multipart/encrypted resulting from applying security services according to [RFC1847]. Luck & Hoeneisen Expires September 9, 2019 [Page 14] Internet-Draft pEp Header Protection March 2019 Signing, but not encrypting, a message with MIME Security with OpenPGP ([RFC4880] and [RFC3156]), yields a message with the following basic MIME structure. If any part directly below multipart/signed is of type message/rfc822, then the property forwarded="no" SHOULD be set. = multipart/signed; protocol="application/pgp-signature"; + multipart/mixed + message/rfc822; forwarded="no"; | [ protected message ] + application/pgp-keys { Content-Disposition: attachment; filename="pEpkey.asc" } + application/pgp-signature No additional requirements exist for a signed but not encrypted message with header protection. 5.1.4. Building the Outer Message for Signed and Encrypted Inner Messages Signing and encrypting a message with MIME Security with OpenPGP [RFC3156], yields a message with the following basic MIME structure: = multipart/encrypted; protocol="application/pgp-encrypted"; + application/pgp-encrypted [ Version: 1 ] + application/octet-stream; name="msg.asc" { Content-Disposition: inline; filename="msg.asc"; } | [ opaque encrypted structure ] | + multipart/mixed + text/plain [ pEp-Wrapped-Message-Info: OUTER ] + message/rfc822; forwarded="no"; | [ protected message ] + application/pgp-keys The header fields of the sub-part of type application/octet-stream must be modified to ensure that: o the Content-Type header field's Luck & Hoeneisen Expires September 9, 2019 [Page 15] Internet-Draft pEp Header Protection March 2019 * "name" parameter is set to the value "msg.asc", and * parameter "forwarded" is set to "no", and o the Content-Disposition header field value is set to "inline" * and the "filename" parameter is set to "msg.asc". 5.1.5. S/MIME Compatibility Interoperability and implementation symmetry between PGP/MIME and S/MIME is on the roadmap of pEp. 6. Candidate Header Fields for Header Protection By default, all headers of the original message SHOULD be protected, with one exception: o the header field "Bcc" MUST NOT be added to the protected headers. 7. Stub Outside Headers The outer message requires a minimal set of headers to be in place for being eligible for transport. This includes the "From", "To", "Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol hereby defined also depends on the "MIME-Version", "Content-Type", "Content-Disposition" and eventually the "Content-Transport-Encoding" header field to be present. Submission and forwarding based on SMTP carries "from" and "receivers" information out-of-band, so that the "From" and "To" header fields are not strictly necessary. Nevertheless, "From", "Date", and at least one destination header field is mandatory as per [RFC5322]. They SHOULD be conserved for reliability. The following header fields should contain a verbatim copy of the header fields of the original message: o Date o From o To o Cc (*) o Bcc (*) Luck & Hoeneisen Expires September 9, 2019 [Page 16] Internet-Draft pEp Header Protection March 2019 The entries with an asterisk mark (*) should only be set if also present in the original message. If signing, but no encryption is applied to the inner message, all other headers of the original message SHOULD be copied verbatim to the outer message as well. Clients which follow pEp standards MUST set the header field value for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which do not adhere to all pEp standards should set the header field value of "Subject" to a descriptive stub value. An example used in practice is o Subject: Encrypted message The following header fields should be initialized with proper values: o Message-ID o Content-Type o Content-Disposition o Content-Transport-Encoding (if necessary) 8. Processing Incoming Email with Protected Headers [[ TODO ]] 8.1. Detecting Header Protection in Incoming Email [[ TODO: Reverse of above. Multiple equivalent specs available. ]] 8.2. Resolving Conflicting Protected and Unprotected Header Fields For the purpose of selecting messages based on search criteria, or just for displaying them, pEp clients may have to temporarily rebuild the unprotected representation of the email (pEp clients may implement a caching mechanism to avoid rebuilding these messages repeatedly, provided they can use a trusted storage for the cache). Every pEp wrapper email MUST contain exactly one multipart/encrypted MIME part, which contains the protected signed-and-encrypted email as an application/octet-stream encoded as a OpenPGP Radix-64. Such a protected email MAY be in turn a pEp wrapper email and contain another protected email which the client MUST try to decrypt recursively. Through recursion, intermediate protected emails will be encountered and header fields encountered therein, protected or Luck & Hoeneisen Expires September 9, 2019 [Page 17] Internet-Draft pEp Header Protection March 2019 not, MUST be ignored for the purpose of rebuilding the unprotected representation of the email. [[ TODO: Describe what happens when the messages do not validate; difference between have-no-key-for-it, and broken-according-to-key- we-have. ]] Values of protected header fields always override the header fields defined in the outer context. A single protected header field requires to discard ALL header fields from the outer context with the same header name. A header field defined in the wrapper message and not in the protected header section, or alternatively present in the protected header section and not in the wrapper message, MUST be present in the unprotected representation of the email. For the purpose of rebuilding the unprotected email, the selection of headers in DKIM is not relevant. The unprotected representation of the email MAY NOT validate to DKIM or SPF rules anymore. 8.3. Processing of Signed-only Email pEp either engages in a signed-and-encrypted communication or in an unsigned plaintext communication. Inbound signatures attached to plaintext messages are duly verified but cannot enhance the perceived quality of the message in the user interface (an invalid signature degrades the perception) ([I-D.birk-pep]). 8.4. Incoming Filter Processing The Mail User Agent may implement outgoing filtering of mails, which may veto, alter, redirect or replicate the messages. The functionality may be implemented on the mailbox server and be configurable through a well-known protocol, e.g., by means of The Sieve Mail-Filtering Language [RFC5490], or be implemented client- side, or in a combination of both. A mailbox server, which is required to process the full range of possible filters, is requiring plaintext access to the header fields. In an end-to-end-encryption context, which pEp enforces by default, upon first reception of the message the mailbox server is limited to see the transport- relevant headers of the outer wrapper message. A pEp client configued to trust the server ("trusted server" setting [I-D.marques-pep-email]) will later download the encrypted message, decrypt it and replace the copy on the server by the decrypted copy. Luck & Hoeneisen Expires September 9, 2019 [Page 18] Internet-Draft pEp Header Protection March 2019 8.4.1. Staged Filtering of Inbound Messages Inbound messages are expected to be delivered to the inbox while still being encrypted. At this point in time, server-side filtering can only evaluate the unprotected header fields in the wrapper message. In an end-to-end-encryption context, which pEp enforces by default, the mailbox server is limited to see the transport-relevant headers of the outer wrapper message only upon first delivery. A pEp client configued to trust the server ("trusted server" setting [I-D.marques-pep-email]) will eventually download the encrypted message, decrypt it locally and replace the copy on the server by the decrypted copy. Server-side message filters SHOULD be able to detect such post-processed messages, and apply the pending filters. The client SHOULD easily reflect the post-filtered messages in the user interface. 8.5. Outgoing Filter Processing The Mail User Agent may implement outgoing filtering of emails, which may veto, alter or replicate the email. They may also hint the MUA to store a copy in an alternate "Sent" folder. Filters which veto the sending or do alter the mail or replicate it (e.g., mass-mail generators) SHOULD be completed priorly to applying protection, and thus also priorly to applying header protection. Redirection to alternate "Sent" folders MUST NOT be decided priorly to applying protection, but MUAs MAY abide from this restriction if they implement the "trusted server" option and the option is selected for the specific mailbox server; in this case, MUAs MUST NOT allow to redirect a message to an untrusted server by these rules, to prevent information leakage to the untrusted server. [[ TODO: Mention implicit filter for minimal color-rating for message replication. ]] [[ TODO: How to produce key-export-mails manually this way? That is, what about non-pEp-mode? ]] 9. Security Considerations [[ TODO ]] Luck & Hoeneisen Expires September 9, 2019 [Page 19] Internet-Draft pEp Header Protection March 2019 10. Implementation Status 10.1. Introduction This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "[...] this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit." 10.2. Current software implementing pEp The following software implementing the pEp protocols (to varying degrees) already exists: o pEp for Outlook as add-on for Microsoft Outlook, release [SRC.pepforoutlook] o pEp for Android (based on a fork of the K9 MUA), release [SRC.pepforandroid] o Enigmail/pEp as add-on for Mozilla Thunderbird, release [SRC.enigmailpep] o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios] pEp for Android, iOS and Outlook are provided by pEp Security, a commercial entity specializing in end-user software implementing pEp while Enigmail/pEp is pursued as community project, supported by the pEp Foundation. All software is available as Free Software and published also in source form. Luck & Hoeneisen Expires September 9, 2019 [Page 20] Internet-Draft pEp Header Protection March 2019 11. Acknowledgements Special thanks go to Krista Bennett for valuable input to this draft and Hernani Marques for reviewing. 12. References 12.1. Normative References [I-D.birk-pep] Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Privacy by Default", draft-birk-pep-03 (work in progress), March 2019. [I-D.ietf-lamps-rfc5751-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", draft-ietf-lamps-rfc5751-bis-12 (work in progress), September 2018. [I-D.marques-pep-email] Marques, H., "pretty Easy privacy (pEp): Email Formats and Protocols", draft-marques-pep-email-02 (work in progress), October 2018. [I-D.melnikov-lamps-header-protection] Melnikov, A., "Considerations for protecting Email header with S/MIME", draft-melnikov-lamps-header-protection-00 (work in progress), October 2018. [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, October 1995, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Luck & Hoeneisen Expires September 9, 2019 [Page 21] Internet-Draft pEp Header Protection March 2019 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 2009, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [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, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . 12.2. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Luck & Hoeneisen Expires September 9, 2019 [Page 22] Internet-Draft pEp Header Protection March 2019 [SRC.enigmailpep] "Source code for Enigmail/pEp", March 2019, . [SRC.pepforandroid] "Source code for pEp for Android", March 2019, . [SRC.pepforios] "Source code for pEp for iOS", March 2019, . [SRC.pepforoutlook] "Source code for pEp for Outlook", March 2019, . Appendix A. Document Changelog [[ RFC Editor: This section is to be removed before publication ]] o draft-luck-lamps-pep-header-protection * Initial version Appendix B. Open Issues [[ RFC Editor: This section should be empty and is to be removed before publication. ]] o Align with specification for MIME Content-Type message/partial * We probably have issues and overlapping specifications about encoding for nested message/rfc822 entities, specified in [RFC2046]. Further study is needed to find and understand the issues. o Signed-only protection needs further study * pEp only does header protection by applying both signing and encryption. Technically it is also possible to sign, but not encrypt the protected messages. This needs futher study. Authors' Addresses Luck & Hoeneisen Expires September 9, 2019 [Page 23] Internet-Draft pEp Header Protection March 2019 Claudio Luck pEp Foundation Oberer Graben 4 CH-8400 Winterthur Switzerland Email: claudio.luck@pep.foundation URI: https://pep.foundation/ Bernie Hoeneisen Ucom Standards Track Solutions GmbH CH-8046 Zuerich Switzerland Phone: +41 44 500 52 44 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) URI: https://ucom.ch/ Luck & Hoeneisen Expires September 9, 2019 [Page 24]