--- 1/draft-ietf-lamps-header-protection-01.txt 2020-11-02 16:13:31.000900328 -0800 +++ 2/draft-ietf-lamps-header-protection-02.txt 2020-11-02 16:13:31.052901635 -0800 @@ -1,21 +1,21 @@ LAMPS Working Group B. Hoeneisen Internet-Draft pEp Foundation -Intended status: Standards Track D. Gillmor -Expires: May 6, 2021 American Civil Liberties Union +Intended status: Standards Track D.K. Gillmor +Expires: 7 May 2021 American Civil Liberties Union A. Melnikov Isode Ltd - November 02, 2020 + 3 November 2020 Header Protection for S/MIME - draft-ietf-lamps-header-protection-01 + draft-ietf-lamps-header-protection-02 Abstract 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. @@ -32,84 +32,82 @@ 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 May 6, 2021. + This Internet-Draft will expire on 7 May 2021. 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 - 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. + 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 1.1. Other Protocols to Protect Email Headers . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10 3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14 4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Additional information . . . . . . . . . . . . . . . 22 A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22 - Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 22 + Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 23 B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23 B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23 - Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction - Privacy and security issues regarding email Header Protection in - S/MIME have been identified for some time. Most current + 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. [RFC8551]): @@ -125,26 +123,26 @@ 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: - o Broken or incomplete implementations + * Broken or incomplete implementations - o Lack of a simple means to distinguish "forwarded message" and + * Lack of a simple means to distinguish "forwarded message" and "wrapped message" (for the sake of Header Protection) - o Not enough guidance with respect to handling of Header Fields on + * 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) [RFC3156] yet. PGP/MIME developers have @@ -162,152 +160,151 @@ 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. 1.1. Other Protocols to Protect Email Headers 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) - [RFC6376], as used by Domain-based Message Authentication, Reporting, - and Conformance (DMARC) [RFC7489]. 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. + confidentiality.[RFC6376], as used by Domain-based Message + Authentication, Reporting, and Conformance (DMARC) [RFC7489]. 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. 1.2. 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.3. Terms The following terms are defined for the scope of this document: - o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A + * 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." 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'. - o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. + * S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. [RFC8551]) - o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) + * PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) - o Message: An Email Message consisting of Header Fields + * Message: An Email Message consisting of Header Fields (collectively called "the Header Section of the message") followed, optionally, by a Body; 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 Field (HF): cf. [RFC5322] Header Fields are lines beginning + * 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. - o Header Section (HS): The Header Section is a sequence of lines of + * 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 bytes that follows the + * 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 [RFC5322]. It is the (bottom) section of Message containing the payload of a Message. Typically, the Body consists of a (possibly multipart) MIME [RFC2045] construct. - o MIME Header Fields: Header Fields describing content of a MIME + * MIME Header Fields: Header Fields describing content of a MIME entity [RFC2045], in particular the MIME structure. Each MIME Header Field name starts with "Content-" prefix. - o MIME Header Section (part): The collection of MIME Header Fields. + * 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 Essential Header Fields (EHF): The minimum set of Header Fields an + * Essential Header Fields (EHF): The minimum set of Header Fields an Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4. - o Header Protection (HP): cryptographic protection of email Header + * Header Protection (HP): cryptographic protection of email Header Sections (or parts of it) for signatures and/or encryption - o Protection Levels (PL): The level of protection applied to a + * Protection Levels (PL): The level of protection applied to a Message, e.g. 'signature and encryption' or 'signature only' (cf. Section 3.2). - o Protected: Portions of a message that have had any Protection + * Protected: Portions of a message that have had any Protection Levels applied. - o Protected Message: A Message that has had any Protection Levels + * Protected Message: A Message that has had any Protection Levels applied. - o Unprotected: Portions of a Message that has had no Protection + * Unprotected: Portions of a Message that has had no Protection Levels applied. - o Unprotected Message: A Message that has had no Protection Levels + * Unprotected Message: A Message that has had no Protection Levels applied. - o Submission Entity: The entity which executes further processing of + * 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) [RFC6409] 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. - o Original Message (OrigM): The Message to be protected before any + * 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. - o Inner Message (InnerM): The Message to be protected which has had + * 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. Section 4.1.2.1). The Inner Message must be the same on the sending and the receiving side. - o Outer Message (OuterM): The Message as provided to the Submission + * 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). - o Receiving User Facing Message (RUFM): The Message used for + * Receiving User Facing Message (RUFM): The Message used for rendering at the receiving side. Typically this is the same as the Inner Message. - o Data Minimization: Data sparseness and hiding of all technically + * Data Minimization: Data sparseness and hiding of all technically concealable information whenever possible. - o Cryptographic Layer, Cryptographic Payload, and Cryptographic + * Cryptographic Layer, Cryptographic Payload, and Cryptographic Envelope are all used as defined in [I-D.dkg-lamps-e2e-mail-guidance] 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, @@ -316,35 +313,35 @@ 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 (Technical) Data Minimization, which includes data sparseness and + * (Technical) Data Minimization, which includes data sparseness and hiding all technically concealable information whenever possible 2.2. Security - o Prevent MITM attacks (cf. [RFC4949]) + * Prevent MITM attacks (cf. [RFC4949]) 2.3. Usability - o Improved User interaction / User experience, in particular at the + * Improved User interaction / User experience, in particular at the receiving side 2.4. Interoperability - o Interoperability with [RFC8551] implementations + * 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). These use cases apply regardless of technology (S/MIME, PGP/MIME, etc.) used to achieve HP. 3.1. Interactions @@ -436,43 +433,43 @@ Messages containing a cryptographic signature, but which are not encrypted. 3.2.2. Out-of-Scope 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): - o Triple wrap + * Triple wrap - o Encryption only + * Encryption only - o Encryption before signature + * Encryption before signature - o Signature and encryption, but: + * Signature and encryption, but: - * Signature fails to validate + - Signature fails to validate - * Signature validates but the signing certificate revoked + - Signature validates but the signing certificate revoked - o Signature only, but: + * Signature only, but: - * with multiple valid signatures, layered atop each other + - with multiple valid signatures, layered atop each other These Protection Levels, as well as any further Protection Levels not listed in Section 3.2.1 are beyond the scope of this document. 4. Specification - This section contains the specification for Header Protection in - S/MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0). + This section contains the specification for Header Protection in S/ + MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0). Note: It is likely that PGP/MIME [RFC3156] will also incorporate 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 MUST implement the "signature and encryption" Protection Level, which SHOULD be used as default on the sending side. @@ -531,25 +528,25 @@ 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 "O: " Outer Message Header Section + * "O: " Outer Message Header Section - o "I: " Message Header Section + * "I: " Message Header Section - o "W: " Wrapper (MIME Header Section) + * "W: " Wrapper (MIME Header Section) O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: 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 @@ -604,21 +601,21 @@ this is not the case, Original Message means the (virtual) Message that would be constructed for sending it as unprotected email. 4.1.2.1. Inner Message Header Fields It is RECOMMENDED that the Inner Message contains all Header Fields of the Original Message with the exception of the following Header Field, which MUST NOT be included within the Inner Message nor within any other protected part of the Message: - o Bcc + * 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.2.2. Wrapper The wrapper is a simple MIME Header Section followed by an empty line preceding the Inner Message (inside the Outer Message Body). The media type of the wrapper MUST be "message/RFC822" and MUST contain @@ -638,34 +635,34 @@ 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 Cryptographic Layer of the protected MIME subtree as per [RFC8551]. The following Header Fields are defined as the Essential Header Fields: - o From + * From - o To (if present in the Original Message) + * To (if present in the Original Message) - o Cc (if present in the Original Message) + * Cc (if present in the Original Message) - o Bcc (if present in the Original Message, see also Section 4.1.2.1 + * Bcc (if present in the Original Message, see also Section 4.1.2.1 and Appendix A.1) - o Date + * Date - o Message-ID + * Message-ID - o Subject + * Subject Further processing by the Submission Entity normally depends on part of these Header Fields, e.g. From and Date HFs are required by [RFC5322]. 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: @@ -694,74 +691,74 @@ (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. [pEp.mixnet].) 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 Content-Type + * Content-Type - o Content-Transfer-Encoding + * Content-Transfer-Encoding - o Content-Disposition + * Content-Disposition The following example shows the MIME Header Section part 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 + * References - o Reply-To + * Reply-To - o In-Reply-To + * In-Reply-To 4.1.2.4.2. Unencrypted Messages 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 [RFC8551]. It may contain further Header Fields, in particular those also present in the Inner Message Header Section. 4.1.2.5. Sending Side Message Processing For a protected Message the following steps are applied before a Message is handed over to the Submission Entity: 4.1.2.5.1. Step 1: Decide on Protection Level and Information Disclosure The implementation which applies protection to a Message must decide: - o Which Protection Level (signature and/or encryption) shall be + * 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. - o Which Header Fields of the Original Message shall be part of the + * 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. Section 4.1.2.4. - o Which of these Header Fields are to be obfuscated? This depends + * 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.2.4. 4.1.2.5.2. Step 2: Compose the Outer Message Header Section Depending on the decision in Section 4.1.2.5.1, 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.) @@ -882,28 +879,31 @@ 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. 9. References 9.1. Normative References [I-D.dkg-lamps-e2e-mail-guidance] Gillmor, D., "Guidance on End-to-End E-mail Security", - draft-dkg-lamps-e2e-mail-guidance-00 (work in progress), - October 2020. + Work in Progress, Internet-Draft, draft-dkg-lamps-e2e- + mail-guidance-00, 31 October 2020, . [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. + Requirements for Header Protection", Work in Progress, + Internet-Draft, draft-ietf-lamps-header-protection- + requirements-01, 29 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, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . @@ -924,33 +924,37 @@ [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, . 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. + Headers for Cryptographic E-mail", Work in Progress, + Internet-Draft, draft-autocrypt-lamps-protected-headers- + 02, 20 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. + Content-Type Header Field Parameter 'forwarded'", Work in + Progress, Internet-Draft, draft-melnikov-iana-reg- + forwarded-00, 4 November 2019, . [I-D.pep-email] Marques, H., "pretty Easy privacy (pEp): Email Formats and - Protocols", draft-pep-email-00 (work in progress), July - 2020. + Protocols", Work in Progress, Internet-Draft, draft-pep- + email-00, 10 July 2020, . [pEp.mixnet] pEp Foundation, "Mixnet", June 2020, . [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, . @@ -1093,23 +1097,23 @@ 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 "O: " Outer Message Header Section + * "O: " Outer Message Header Section - o "I: " Message Header Section + * "I: " Message Header Section O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: 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. @@ -1142,109 +1146,114 @@ Original Message Header Section (cf. Section 4.1.2.1). The Inner Message Body is the same as the Original Message Body. The Original Message itself may contain any MIME structure. Appendix C. Document Changelog [[ RFC Editor: This section is to be removed before publication ]] - o draft-ietf-lamps-header-protection-01 - * Add DKG as co-author + * draft-ietf-lamps-header-protection-02 + - editorial changes / improve language - * Partial Rewrite of Abstract and Introduction [HB/AM/DKG] + * draft-ietf-lamps-header-protection-01 - * Adding definiations for Cryptographic Layer, Cryptographic + - 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 [I-D.dkg-lamps-e2e-mail-guidance]) [DKG] - * Enhanced MITM Definition to include Machine- / Meddler-in-the- + - Enhanced MITM Definition to include Machine- / Meddler-in-the- middle [HB] - * Relaxed definition of Original message, which may not be of + - 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 + - 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 + - Updated Scope of Protection Levels according to WG discussion during IETF-108 [HB] - * Obfuscation recommendation only for Subject and Message-Id and + - 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 + - Removed (commented out) Header Field Flow Figure (it appeared to be confusing as is was) [HB] - o draft-ietf-lamps-header-protection-00 + * draft-ietf-lamps-header-protection-00 - * Initial version (text partially taken over from + - Initial version (text partially taken over from [I-D.ietf-lamps-header-protection-requirements] Appendix D. 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) + * Ensure "protected header" (Ex-Memory-Hole) option is (fully) compliant with the MIME standard, in particular also [RFC2046], Section 5.1. (Multipart Media Type) Appendix B.1.1.1. - o More examples (e.g. in Section 4.1.2.5) + * More examples (e.g. in Section 4.1.2.5) - o Should Outer Message Header Section (as received) be preserved for + * Should Outer Message Header Section (as received) be preserved for the user? (Section 4.1.3.2.2) - o Decide on whether or not merge requirements from + * Decide on whether or not merge requirements from [I-D.ietf-lamps-header-protection-requirements] into this document. - o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to + * Decide what parts of [I-D.autocrypt-lamps-protected-headers] to merge into this document. - o Enhance Introduction Section 1 and Problem Statement (Section 2). + * Enhance Introduction Section 1 and Problem Statement (Section 2). - o Decide on whether or not specification for more legacy HP + * Decide on whether or not specification for more legacy HP requirements should be added to this document (Section 3.1.2). - o Verify simple backward compatibility case (Receiving Side MIME- + * Verify simple backward compatibility case (Receiving Side MIME- Conformant) is working; once solution is stable and update paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1 accordingly. - o Verify ability to distinguish between Messages with Header + * Verify ability to distinguish between Messages with Header Protection as specified in this document and legacy clients and update Section 3.1 accordingly. - o Improve definitions of Protection Levels and enhance list of + * Improve definitions of Protection Levels and enhance list of Protection Levels (Section 3.2, Section 4). - o Privacy Considerations Section 6 + * Privacy Considerations Section 6 - o Security Considerations Section 5 + * Security Considerations Section 5 Authors' Addresses Bernie Hoeneisen pEp Foundation Oberer Graben 4 - CH-8400 Winterthur + CH- CH-8400 Winterthur Switzerland Email: bernie.hoeneisen@pep.foundation URI: https://pep.foundation/ Daniel Kahn Gillmor American Civil Liberties Union 125 Broad St. - New York, NY 10004 - USA + New York, NY, 10004 + United States of America Email: dkg@fifthhorseman.net Alexey Melnikov Isode Ltd 14 Castle Mews - Hampton, Middlesex TW12 2NP - UK + Hampton, Middlesex + TW12 2NP + United Kingdom Email: alexey.melnikov@isode.com