pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland bernie.hoeneisen@pep.foundation https://pep.foundation/

American Civil Liberties Union

125 Broad St. New York, NY 10004 USA dkg@fifthhorseman.net

Isode Ltd

14 Castle Mews Hampton, Middlesex TW12 2NP UK alexey.melnikov@isode.com

Security LAMPS Working Group Internet-Draft S/MIME version 3.1 has introduced a feasible standardized option to accomplish Header Protection. However, implementations of Header Protection can cause rendering issues on the receiving side. Clearer specifications regarding message processing, particularly with respect to header sections, are needed in order to resolve these rendering issues. In order to help implementers to correctly compose and render email messages with Header Protection, this document updates S/MIME Header Protection specifications with additional guidance on MIME format, sender and receiver processing.

Privacy and security issues regarding email Header Protection in S/MIME have been identified for some time. 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. For example, lack of header protection allows an attacker to substitute the message subject and/or author. A way to provide end-to-end protection for the Header Section of an email message has been standardized for S/MIME version 3.1 and later (cf. ): 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. Unfortunately, implementations of Header Protection can cause rendering issues on the receiving side. In some cases, the user sees an attachment suggesting a forwarded email message, which – in fact – contains the protected email message that should be rendered directly. For these cases, the user can click on the attachment to view the protected message. However, there have also been reports of email clients displaying garbled text, or sometimes nothing at all. In those cases the email clients on the receiving side are (most likely) not fully MIME-capable. The following shortcomings have been identified to cause these issues: Broken or incomplete implementations Lack of a simple means to distinguish “forwarded message” and “wrapped message” (for the sake of Header Protection) Not enough guidance with respect to handling of Header Fields on both the sending and the receiving side Furthermore, the need (technical) Data Minimization, which includes data sparseness and hiding all technically concealable information, has grown in importance over the past several years. In addition, backwards compatibility must be considered when it is possible to do so without compromising privacy and security. No mechanism for Header Protection has been standardized for PGP/MIME (Pretty Good Privacy) yet. PGP/MIME developers have implemented ad-hoc header-protection, and would like to see a specification that is applicable to both S/MIME and PGP/MIME. This document describes the problem statement (), generic use cases () and the specification for Header Protection () with guidance on MIME format, sender and receiver processing . defines the requirements that this specification is based on. This document is in an early draft state and contains a proposal on which to base future discussions of this topic. In any case, the final mechanism is to be determined by the IETF LAMPS WG.

A range of protocols for the protection of electronic mail (email) exists, which allows one 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) , as used by Domain-based Message Authentication, Reporting, and Conformance (DMARC) . These protocols provide a domain-based reputation mechanism that can be used to mitigate some forms of unsolicited email (spam). At the same time, these protocols can provide a level of cryptographic integrity and authenticity for some headers, depending on how they are used. However, integrity protection and proof of authenticity are both tied to the domain name of the sending e-mail address, not the sending address itself, so these protocols do not provide end-to-end protection, and are incapable of providing any form of confidentiality.

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 .

The following terms are defined for the scope of this document: Man-in-the-middle (MITM) attack: cf. , 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.” Note: Historically, MITM has stood for ‘Man-in-the-middle’. However, to indicate that the entity in the middle is not always a human attacker, MITM can also stand for ‘Machine-in-the-middle’ or ‘Meddler-in-the-middle’. S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. ) PGP/MIME: MIME Security with OpenPGP (cf. ) Message: An Email Message consisting of Header Fields (collectively called “the Header Section of the message”) followed, optionally, by a Body; cf. . 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. . Header Field (HF): cf. Header Fields are lines beginning with a field name, followed by a colon (“:”), followed by a field body (value), and terminated by CRLF. Header Section (HS): The Header Section is a sequence of lines of characters with special syntax as defined in . It is the (top) section of a Message containing the Header Fields. Body: The Body is simply a sequence of bytes 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 . It is the (bottom) section of Message containing the payload of a Message. Typically, the Body consists of a (possibly multipart) MIME construct. MIME Header Fields: Header Fields describing content of a MIME entity , in particular the MIME structure. Each MIME Header Field name starts with “Content-“ prefix. 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. Essential Header Fields (EHF): The minimum set of Header Fields an Outer Message Header Section SHOULD contain; cf. . Header Protection (HP): cryptographic protection of email Header Sections (or parts of it) for signatures and/or encryption Protection Levels (PL): The level of protection applied to a Message, e.g. ‘signature and encryption’ or ‘signature only’ (cf. ). Protected: Portions of a message that have had any Protection Levels applied. Protected Message: A Message that has had any Protection Levels applied. Unprotected: Portions of a Message that has had no Protection Levels applied. Unprotected Message: A Message that has had no Protection Levels applied. Submission Entity: The entity which executes further processing of the Message (incl. transport towards the receiver), after protection measures have been applied to the Message. Note: The Submission Entity varies among implementations, mainly depending on the stage where protection measures are applied: E.g. a Message Submission Agent (MSA) or another (proprietary) solution. The latter is particularly relevant, if protection is implemented as a plugin solution. Some implementations may determine the destination recipients by reading the To, Cc and Bcc Header Fields of the Outer Message. Original Message (OrigM): The Message to be protected before any protection-related processing has been applied on the sending side. If the source is not a “message/rfc822” Message, OrigM is defined as the “virtual” Message that would be constructed for sending it as unprotected email. Inner Message (InnerM): The Message to be protected which has had wrapping and protection measures aapplied on the sending side OR the resulting Message once decryption and unwrapping on the receiving side has been performed. Typically, the Inner Message is in clear text. The Inner Message is a subset of (or the same as) the Original Message (cf. ). The Inner Message must be the same on the sending and the receiving side. Outer Message (OuterM): The Message as provided to the Submission Entity or received from the last hop respectively. The Outer Message normally differs on the sending and the receiving side (e.g. new Header Fields are added by intermediary nodes). Receiving User Facing Message (RUFM): The Message used for rendering at the receiving side. Typically this is the same as the Inner Message. Data Minimization: Data sparseness and hiding of all technically concealable information whenever possible. Cryptographic Layer, Cryptographic Payload, and Cryptographic Envelope are all used as defined in

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. ]]

(Technical) Data Minimization, which includes data sparseness and hiding all technically concealable information whenever possible

Prevent MITM attacks (cf. )

Improved User interaction / User experience, in particular at the receiving side

Interoperability with implementations

In the following, the reader can find a list of the generic use cases that need to be addressed for Messages with Header Protection (HP). These use cases apply regardless of technology (S/MIME, PGP/MIME, etc.) used to achieve HP.

The following use cases assume that at least the sending side supports Header Protection as specified in this document. Receiving sides that support this specification are expected to be able to distinguish between Messages that use Header Protection as specified in this document, and (legacy) Mail User Agents (MUAs) which do not implement this specification. [[ TODO: Verify once solution is stable and update last sentence. ]]

Both the sending and receiving side (fully) support Header Protection as specified in this document. The main use case is specified in .

Regarding backward compatibility, the main distinction is based on whether or not the receiving side conforms to MIME according to , ff., which in particular also includes Section 2 of on “MIME Conformance”. The following excerpt is contextually relevant:

[[ TODO: The compatibility of legacy HP systems with this new solution, and how to handle issues surrounding future maintenance for these legacy systems, will be decided by the LAMPS WG. ]]

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 , ff. (cf. ). This use case is specified in . Note: This case should perform as expected if the sending side applies this specification as outlined in . [[ TODO: Verify once solution is stable and update last sentence. ]]

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 , ff. (cf. ). This use case is specified in .

The following Protection Levels are in scope for this document: a) Signature and encryption

b) Signature only

Legacy implementations, implementations not (fully) compliant with this document or corner-cases may lead to further Protection Levels to appear on the receiving side, such as (list not exhaustive): Triple wrap Encryption only Encryption before signature Signature and encryption, but: Signature fails to validate Signature validates but the signing certificate revoked Signature only, but: with multiple valid signatures, layered atop each other These Protection Levels, as well as any further Protection Levels not listed in are beyond the scope of this document.

This section contains the specification for Header Protection in S/MIME to update and clarify Section 3.1 of (S/MIME 4.0). Note: It is likely that PGP/MIME will also incorporate this specification or parts of it. This specification applies to the Protection Levels “signature & encryption” and “signature only” (cf. ): Sending and receiving sides MUST implement the “signature and encryption” Protection Level, which SHOULD be used as default on the sending side. Certain implementations may decide to send “signature only” Messages, depending on the circumstances and customer requirements. Sending sides MAY and receiving sides MUST implement “signature only” Protection Level. It generally is NOT RECOMMENDED to send a Message with any other Protection Level. On the other hand, the receiving side must be prepared to receive Messages with other Protection Levels. [[ TODO: Further study is necessary to determine whether - and if yes to what extent - additional guidance for handling messages with other Protection Levels, e.g. “encryption only” at the receiving side should be included in this document. ]]

This section applies to the main use case, where the sending and receiving side (fully) support Header Protection as specified herein (cf. ). Note: The sending side specification of the main use case is also applicable to the cases where the sending side (fully) supports Header Protection as specified herein, while the receiving side does not, but is MIME-conformant according to , ff. (cf. and ). Further backward compatibility cases are defined in .

As per S/MIME version 3.1 and later (cf. ), 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 . The simplified (cryptographic overhead not shown) MIME structure of such an Email Message looks as follows:

]]>

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: Subject: Meeting at my place O: From: "Alexey Melnikov" 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" I: Message-ID: 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 (cf. ), 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 (instead of the currently standardized and above defined format).

To ease explanation, the following describes the case where an Original (message/rfc822) Message to be protected is present. If this is not the case, Original Message means the (virtual) Message that would be constructed for sending it as unprotected email.

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 ). Certain MUAs cannot properly decrypt Messages with Bcc recipients. ]]

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 . The wrapper unambiguously delimits the Inner Message from the rest of the Message.

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

To maximize Privacy, it is strongly RECOMMENDED to follow the principle of Data Minimization (cf. ). 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 Cryptographic Layer of the protected MIME subtree as per . The following Header Fields are defined as the Essential Header Fields: From To (if present in the Original Message) Cc (if present in the Original Message) Bcc (if present in the Original Message, see also and ) Date Message-ID Subject Further processing by the Submission Entity normally depends on part of these Header Fields, e.g. From and Date HFs are required by . Furthermore, not including certain Header Fields may trigger spam detection to flag the Message, and/or lead to user experience (UX) issues. For further Data Minimization, the value of the Subject Header Field SHOULD be obfuscated as follows:

and it is RECOMMENDED to replace the Message-ID by a new randomly generated Message-ID. In addition, the value of other Essential Header Fields MAY be obfuscated. Non-Essential Header Fields SHOULD be omitted from the Outer Message Header Section where possible. If Non-essential Header Fields are included in the Outer Message Header Section, those MAY be obfuscated too. Header Fields that are not obfuscated should contain the same values as in the Original Message. If an implementation obfuscates the From, To, and/or Cc Header Fields, it may need to provide access to the clear text content of these Header Fields to the Submission Entity for processing purposes. This is particularly relevant, if proprietary Submission Entities are used. Obfuscation of Header Fields may adversely impact spam filtering. (A use case for obfuscation of all Outer Message Header Fields is routing email through the use of onion routing or mix networks, e.g. .) The MIME Header Section part is the collection of MIME Header Fields describing the following MIME structure as defined in . A MIME Header Section part typically includes the following Header Fields: Content-Type Content-Transfer-Encoding Content-Disposition The following example shows the MIME Header Section part of an S/MIME signed Message (using application/pkcs7-mime with SignedData):

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.: References Reply-To In-Reply-To

The Outer Message Header Section of unencrypted Messages SHOULD contain at least the Essential Header Fields and, in addition, MUST contain the Header Fields of the MIME Header Section part to describe Cryptographic Layer of the protected MIME subtree as per . It may contain further Header Fields, in particular those also present in the Inner Message Header Section.

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

The implementation which applies protection to a Message must decide: Which Protection Level (signature and/or encryption) shall be applied to the Message? This depends on user request and/or local policy as well as availability of cryptographic keys. Which Header Fields of the Original 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. . 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. .

Depending on the decision in , the implementation shall compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.) Outer Header Fields that are not obfuscated should contain the same values as in the Original Message (except for MIME Header Section part, which depends on the Protection Level selected in ).

Depending on the Protection Level selected in , the implementation applies signature and/or encryption to the Original Message, including the wrapper (as per ), and sets the resulting package as the Outer Message Body. The resulting (Outer) Message is then typically handed over to the Submission Entity. [[ TODO: Example ]]

The Receiving User Facing Message SHOULD be a verbatim copy of the Inner Message.

When a protected Message is received, the following steps are applied:

Depending on the Protection Level, the received Message is decrypted and/or its signature is checked as per .

The Receiving User Facing Message is constructed according to . The resulting Message is handed over for further processing, which typically involves rendering it for the user.

[[ TODO: Signature valid, etc. ]]

This section applies to the case where the sending side (fully) supports Header Protection as specified in this document, while the receiving side does not support this specification, but is MIME-conformant according to , ff. (cf. and ) The sending side specification of the main use case (cf. ) MUST ensure that receiving sides can still recognize and display or offer to display the encapsulated data in accordance with its media type (cf. , Section 2). In particular, receiving sides that do not support this specification, but are MIME-conformant according to , ff. can still recognize and display the Message intended for the user. [[ TODO: Verify once solution is stable and update last sentence. ]]

This section applies to cases where the sending side (fully) supports Header Protection as specified in this document, while the receiving side neither supports this specification nor is MIME-conformant according to , ff. (cf. and ). describes a possible way to achieve backward compatibility with existing S/MIME (and PGP/MIME) implementations that predate this specification and are not MIME-conformant (Legacy Display) either. It mainly focuses on email clients that do not render emails which utilize header protection in a user friendly manner, which may confuse the user. While this has been observed occasionally in PGP/MIME (cf. ), the extent of this problem with S/MIME implementations is still unclear. (Note: At this time, none of the samples in apply header protection as specified in Section 3.1 of , which is wrapping as Media Type “message/RFC822”.) Should serious backward compatibility issues with rendering at the receiving side be discovered, the Legacy Display format described in may serve as a basis to mitigate those issues (cf. ). Another variant of backward compatibility has been implemented by pEp , i.e. pEp Email Format 1.0. At this time pEp has implemented this for PGP/MIME, but not yet S/MIME.

[[ TODO ]]

[[ TODO ]]

This document requests no action from IANA. [[ RFC Editor: This section may be removed before publication. ]]

The authors would like to thank the following people who have provided helpful comments and suggestions for this document: Berna Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. 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 likely to be updated regarding header protection. This document describes the problem statement, generic use cases, and requirements of header protection. End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common failures. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.Message relay is unaffected, and continues to use SMTP over port 25.When conforming to this document, message submission uses the protocol specified here, normally over port 587.This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK] Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document defines a new Content-Type header field parameter named "forwarded" for "message/rfc822" and "message/global" media types, and its registration with IANA. This document describes a common strategy to extend the end-to-end cryptographic protections provided by PGP/MIME, etc. to protect message headers in addition to message bodies. In addition to protecting the authenticity and integrity of headers via signatures, it also describes how to preserve the confidentiality of the Subject header. The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption a viability for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). pEp Foundation

Messages containing at least one recipient address in the Bcc header field may appear in up to three different variants: 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. 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 addresses. 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). 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 method of the alternatives (2a, 2b, and 2c) 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.

Note: Per an explicit request by the chair of the LAMPS WG to only present one option for the specification, the following text has been stripped from the main body of the draft. It is preserved in an Appendix for the time being and may be moved back to the main body or deleted, depending on the decision of the LAMPS WG.

Currently there are two options in discussion: The option according to the current S/MIME specification (cf. ) An alternative option that is based on the former “memory hole” approach (cf. )

Note: This is currently described in the main part of this document.

An alternative option (based on the former autocrypt “Memory Hole” approach) to be considered, is described in . Unlike the option described in , 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: 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. provides some examples for testing this. MIME-conformance, i.e. whether or not this option is (fully) MIME-conformant ff., in particular also Section 5.1. of on “Multipart Media Type). In the following an excerpt of paragraphs that may be relevant in this context:

The MIME structure of an Email Message looks as follows:

]]>

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: Subject: Meeting at my place O: From: "Alexey Melnikov" 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" I: Message-ID: 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 (cf. ). The Inner Message Body is the same as the Original Message Body. The Original Message itself may contain any MIME structure.

[[ RFC Editor: This section is to be removed before publication ]] draft-ietf-lamps-header-protection-01 Add DKG as co-author Partial Rewrite of Abstract and Introduction [HB/AM/DKG] Adding definiations for Cryptographic Layer, Cryptographic Payload, and Cryptographic Envelope (reference to ) [DKG] Enhanced MITM Definition to include Machine- / Meddler-in-the-middle [HB] Relaxed definition of Original message, which may not be of type “message/rfc822” [HB] Move “memory hole” option to the Appendix (on request by Chair to only maintain one option in the specification) [HB] Updated Scope of Protection Levels according to WG discussion during IETF-108 [HB] Obfuscation recommendation only for Subject and Message-Id and distinguish between Encrypted and Unencrypted Messages [HB] Removed (commented out) Header Field Flow Figure (it appeared to be confusing as is was) [HB] draft-ietf-lamps-header-protection-00 Initial version (text partially taken over from

[[ RFC Editor: This section should be empty and is to be removed before publication. ]] Ensure “protected header” (Ex-Memory-Hole) option is (fully) compliant with the MIME standard, in particular also , Section 5.1. (Multipart Media Type) . More examples (e.g. in ) Should Outer Message Header Section (as received) be preserved for the user? () Decide on whether or not merge requirements from into this document. Decide what parts of to merge into this document. Enhance Introduction and Problem Statement (). Decide on whether or not specification for more legacy HP requirements should be added to this document (). Verify simple backward compatibility case (Receiving Side MIME-Conformant) is working; once solution is stable and update paragraphs in , and accordingly. Verify ability to distinguish between Messages with Header Protection as specified in this document and legacy clients and update accordingly. Improve definitions of Protection Levels and enhance list of Protection Levels (, ). Privacy Considerations Security Considerations