idnits 2.17.1 draft-ietf-lamps-header-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (3 November 2020) is 1241 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DKG' is mentioned on line 1167, but not defined == Missing Reference: 'HB' is mentioned on line 1185, but not defined == Outdated reference: A later version (-01) exists of draft-dkg-lamps-e2e-mail-guidance-00 ** Downref: Normative reference to an Informational draft: draft-dkg-lamps-e2e-mail-guidance (ref. 'I-D.dkg-lamps-e2e-mail-guidance') ** Downref: Normative reference to an Informational draft: draft-ietf-lamps-header-protection-requirements (ref. 'I-D.ietf-lamps-header-protection-requirements') == Outdated reference: A later version (-02) exists of draft-pep-email-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group B. Hoeneisen 3 Internet-Draft pEp Foundation 4 Intended status: Standards Track D.K. Gillmor 5 Expires: 7 May 2021 American Civil Liberties Union 6 A. Melnikov 7 Isode Ltd 8 3 November 2020 10 Header Protection for S/MIME 11 draft-ietf-lamps-header-protection-02 13 Abstract 15 S/MIME version 3.1 has introduced a feasible standardized option to 16 accomplish Header Protection. However, implementations of Header 17 Protection can cause rendering issues on the receiving side. Clearer 18 specifications regarding message processing, particularly with 19 respect to header sections, are needed in order to resolve these 20 rendering issues. 22 In order to help implementers to correctly compose and render email 23 messages with Header Protection, this document updates S/MIME Header 24 Protection specifications with additional guidance on MIME format, 25 sender and receiver processing. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 7 May 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Other Protocols to Protect Email Headers . . . . . . . . 4 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 65 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8 72 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8 73 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10 74 3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10 76 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14 80 4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18 81 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18 82 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18 83 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 9.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Appendix A. Additional information . . . . . . . . . . . . . . . 22 92 A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22 93 Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 23 94 B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23 95 B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23 96 Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25 97 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 Privacy and security issues regarding email Header Protection in S/ 103 MIME have been identified for some time. Most current 104 implementations of cryptographically-protected electronic mail 105 protect only the body of the message, which leaves significant room 106 for attacks against otherwise-protected messages. For example, lack 107 of header protection allows an attacker to substitute the message 108 subject and/or author. 110 A way to provide end-to-end protection for the Header Section of an 111 email message has been standardized for S/MIME version 3.1 and later 112 (cf. [RFC8551]): 114 In order to protect outer, non-content-related message header 115 fields (for instance, the "Subject", "To", "From", and "Cc" 116 fields), the sending client MAY wrap a full MIME message in a 117 message/RFC822 wrapper in order to apply S/MIME security services 118 to these header fields. 120 Unfortunately, implementations of Header Protection can cause 121 rendering issues on the receiving side. In some cases, the user sees 122 an attachment suggesting a forwarded email message, which - in fact - 123 contains the protected email message that should be rendered 124 directly. For these cases, the user can click on the attachment to 125 view the protected message. However, there have also been reports of 126 email clients displaying garbled text, or sometimes nothing at all. 127 In those cases the email clients on the receiving side are (most 128 likely) not fully MIME-capable. 130 The following shortcomings have been identified to cause these 131 issues: 133 * Broken or incomplete implementations 135 * Lack of a simple means to distinguish "forwarded message" and 136 "wrapped message" (for the sake of Header Protection) 138 * Not enough guidance with respect to handling of Header Fields on 139 both the sending and the receiving side 141 Furthermore, the need (technical) Data Minimization, which includes 142 data sparseness and hiding all technically concealable information, 143 has grown in importance over the past several years. In addition, 144 backwards compatibility must be considered when it is possible to do 145 so without compromising privacy and security. 147 No mechanism for Header Protection has been standardized for PGP/MIME 148 (Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have 149 implemented ad-hoc header-protection, and would like to see a 150 specification that is applicable to both S/MIME and PGP/MIME. 152 This document describes the problem statement (Section 2), generic 153 use cases (Section 3) and the specification for Header Protection 154 (Section 4) with guidance on MIME format, sender and receiver 155 processing . 157 [I-D.ietf-lamps-header-protection-requirements] defines the 158 requirements that this specification is based on. 160 This document is in an early draft state and contains a proposal on 161 which to base future discussions of this topic. In any case, the 162 final mechanism is to be determined by the IETF LAMPS WG. 164 1.1. Other Protocols to Protect Email Headers 166 A range of protocols for the protection of electronic mail (email) 167 exists, which allows one to assess the authenticity and integrity of 168 the email headers section or selected Header Fields from the domain- 169 level perspective, specifically DomainKeys Identified Mail (DKIM) 170 However, integrity protection and proof of authenticity are both tied 171 to the domain name of the sending e-mail address, not the sending 172 address itself, so these protocols do not provide end-to-end 173 protection, and are incapable of providing any form of 174 confidentiality.[RFC6376], as used by Domain-based Message 175 Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These 176 protocols provide a domain-based reputation mechanism that can be 177 used to mitigate some forms of unsolicited email (spam). At the same 178 time, these protocols can provide a level of cryptographic integrity 179 and authenticity for some headers, depending on how they are used. 181 1.2. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 1.3. Terms 189 The following terms are defined for the scope of this document: 191 * Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 192 form of active wiretapping attack in which the attacker intercepts 193 and selectively modifies communicated data to masquerade as one or 194 more of the entities involved in a communication association." 196 Note: Historically, MITM has stood for '_Man_-in-the-middle'. 197 However, to indicate that the entity in the middle is not always a 198 human attacker, MITM can also stand for 'Machine-in-the-middle' or 199 'Meddler-in-the-middle'. 201 * S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. 202 [RFC8551]) 204 * PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) 206 * Message: An Email Message consisting of Header Fields 207 (collectively called "the Header Section of the message") 208 followed, optionally, by a Body; cf. [RFC5322]. 210 Note: To avoid ambiguity, this document does not use the terms 211 "Header" or "Headers" in isolation, but instead always uses 212 "Header Field" to refer to the individual field and "Header 213 Section" to refer to the entire collection; cf. [RFC5322]. 215 * Header Field (HF): cf. [RFC5322] Header Fields are lines beginning 216 with a field name, followed by a colon (":"), followed by a field 217 body (value), and terminated by CRLF. 219 * Header Section (HS): The Header Section is a sequence of lines of 220 characters with special syntax as defined in [RFC5322]. It is the 221 (top) section of a Message containing the Header Fields. 223 * Body: The Body is simply a sequence of bytes that follows the 224 Header Section and is separated from the Header Section by an 225 empty line (i.e., a line with nothing preceding the CRLF); cf 226 [RFC5322]. It is the (bottom) section of Message containing the 227 payload of a Message. Typically, the Body consists of a (possibly 228 multipart) MIME [RFC2045] construct. 230 * MIME Header Fields: Header Fields describing content of a MIME 231 entity [RFC2045], in particular the MIME structure. Each MIME 232 Header Field name starts with "Content-" prefix. 234 * MIME Header Section (part): The collection of MIME Header Fields. 235 "MIME Header Section" refers to a Header Sections that contains 236 only MIME Header Fields, whereas "MIME Header Section part" refers 237 to the MIME Header Fields of a Header Section that - in addition 238 to MIME Header Fields - also contains non-MIME Header Fields. 240 * Essential Header Fields (EHF): The minimum set of Header Fields an 241 Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4. 243 * Header Protection (HP): cryptographic protection of email Header 244 Sections (or parts of it) for signatures and/or encryption 246 * Protection Levels (PL): The level of protection applied to a 247 Message, e.g. 'signature and encryption' or 'signature only' (cf. 248 Section 3.2). 250 * Protected: Portions of a message that have had any Protection 251 Levels applied. 253 * Protected Message: A Message that has had any Protection Levels 254 applied. 256 * Unprotected: Portions of a Message that has had no Protection 257 Levels applied. 259 * Unprotected Message: A Message that has had no Protection Levels 260 applied. 262 * Submission Entity: The entity which executes further processing of 263 the Message (incl. transport towards the receiver), after 264 protection measures have been applied to the Message. 266 Note: The Submission Entity varies among implementations, mainly 267 depending on the stage where protection measures are applied: E.g. 268 a Message Submission Agent (MSA) [RFC6409] or another 269 (proprietary) solution. The latter is particularly relevant, if 270 protection is implemented as a plugin solution. Some 271 implementations may determine the destination recipients by 272 reading the To, Cc and Bcc Header Fields of the Outer Message. 274 * Original Message (OrigM): The Message to be protected before any 275 protection-related processing has been applied on the sending 276 side. If the source is not a "message/rfc822" Message, OrigM is 277 defined as the "virtual" Message that would be constructed for 278 sending it as unprotected email. 280 * Inner Message (InnerM): The Message to be protected which has had 281 wrapping and protection measures aapplied on the sending side OR 282 the resulting Message once decryption and unwrapping on the 283 receiving side has been performed. Typically, the Inner Message 284 is in clear text. The Inner Message is a subset of (or the same 285 as) the Original Message (cf. Section 4.1.2.1). The Inner 286 Message must be the same on the sending and the receiving side. 288 * Outer Message (OuterM): The Message as provided to the Submission 289 Entity or received from the last hop respectively. The Outer 290 Message normally differs on the sending and the receiving side 291 (e.g. new Header Fields are added by intermediary nodes). 293 * Receiving User Facing Message (RUFM): The Message used for 294 rendering at the receiving side. Typically this is the same as 295 the Inner Message. 297 * Data Minimization: Data sparseness and hiding of all technically 298 concealable information whenever possible. 300 * Cryptographic Layer, Cryptographic Payload, and Cryptographic 301 Envelope are all used as defined in 302 [I-D.dkg-lamps-e2e-mail-guidance] 304 2. Problem Statement 306 The LAMPS charter contains the following Work Item: 308 Update the specification for the cryptographic protection of email 309 headers - both for signatures and encryption - to improve the 310 implementation situation with respect to privacy, security, 311 usability and interoperability in cryptographically-protected 312 electronic mail. Most current implementations of 313 cryptographically-protected electronic mail protect only the body 314 of the message, which leaves significant room for attacks against 315 otherwise-protected messages. 317 In the following a set of challenges to be addressed: 319 [[ TODO: Enhance this section, add more items to the following. ]] 321 2.1. Privacy 323 * (Technical) Data Minimization, which includes data sparseness and 324 hiding all technically concealable information whenever possible 326 2.2. Security 328 * Prevent MITM attacks (cf. [RFC4949]) 330 2.3. Usability 332 * Improved User interaction / User experience, in particular at the 333 receiving side 335 2.4. Interoperability 337 * Interoperability with [RFC8551] implementations 339 3. Use Cases 341 In the following, the reader can find a list of the generic use cases 342 that need to be addressed for Messages with Header Protection (HP). 343 These use cases apply regardless of technology (S/MIME, PGP/MIME, 344 etc.) used to achieve HP. 346 3.1. Interactions 348 The following use cases assume that at least the sending side 349 supports Header Protection as specified in this document. Receiving 350 sides that support this specification are expected to be able to 351 distinguish between Messages that use Header Protection as specified 352 in this document, and (legacy) Mail User Agents (MUAs) which do not 353 implement this specification. 355 [[ TODO: Verify once solution is stable and update last sentence. ]] 357 3.1.1. Main Use Case 359 Both the sending and receiving side (fully) support Header Protection 360 as specified in this document. 362 The main use case is specified in Section 4.1. 364 3.1.2. Backward Compatibility Use Cases 366 Regarding backward compatibility, the main distinction is based on 367 whether or not the receiving side conforms to MIME according to 368 [RFC2046], ff., which in particular also includes Section 2 of 369 [RFC2049] on "MIME Conformance". The following excerpt is 370 contextually relevant: 372 A mail user agent that is MIME-conformant MUST: 374 [...] 376 -- Recognize and display at least the RFC822 message 377 encapsulation (message/rfc822) in such a way as to 378 preserve any recursive structure, that is, displaying 379 or offering to display the encapsulated data in 380 accordance with its media type. 382 -- Treat any unrecognized subtypes as if they were 383 "application/octet-stream". 385 [...] 387 An MUA that meets the above conditions is said to be MIME- 388 conformant. A MIME-conformant MUA is assumed to be "safe" to send 389 virtually any kind of properly-marked data to users of such mail 390 systems, because these systems are, at a minimum, capable of treating 391 the data as undifferentiated binary, and will not simply 392 splash it onto the screen of unsuspecting users. 394 [[ TODO: The compatibility of legacy HP systems with this new 395 solution, and how to handle issues surrounding future maintenance for 396 these legacy systems, will be decided by the LAMPS WG. ]] 398 3.1.2.1. Receiving Side MIME-Conformant 400 The sending side (fully) supports Header Protection as specified in 401 this document, while the receiving side does not support this 402 specification. However, the receiving side is MIME-conformant 403 according to [RFC2045], ff. (cf. Section 3.1.2). 405 This use case is specified in Section 4.2.1. 407 Note: This case should perform as expected if the sending side 408 applies this specification as outlined in Section 4.1. 410 [[ TODO: Verify once solution is stable and update last sentence. ]] 412 3.1.2.2. Receiving Side Not MIME-Conformant 414 The sending side (fully) supports Header Protection as specified in 415 this document, while the receiving side does not support this 416 specification. Furthermore, the receiving side is *not* MIME- 417 conformant according to [RFC2045], ff. (cf. Section 3.1.2). 419 This use case is specified in Section 4.2.2. 421 3.2. Protection Levels 423 3.2.1. In-Scope 425 The following Protection Levels are in scope for this document: 427 a) Signature and encryption 429 Messages containing a cryptographic signature, which are also 430 encrypted. 432 b) Signature only 434 Messages containing a cryptographic signature, but which are not 435 encrypted. 437 3.2.2. Out-of-Scope 439 Legacy implementations, implementations not (fully) compliant with 440 this document or corner-cases may lead to further Protection Levels 441 to appear on the receiving side, such as (list not exhaustive): 443 * Triple wrap 445 * Encryption only 447 * Encryption before signature 449 * Signature and encryption, but: 451 - Signature fails to validate 453 - Signature validates but the signing certificate revoked 455 * Signature only, but: 457 - with multiple valid signatures, layered atop each other 459 These Protection Levels, as well as any further Protection Levels not 460 listed in Section 3.2.1 are beyond the scope of this document. 462 4. Specification 464 This section contains the specification for Header Protection in S/ 465 MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0). 467 Note: It is likely that PGP/MIME [RFC3156] will also incorporate this 468 specification or parts of it. 470 This specification applies to the Protection Levels "signature & 471 encryption" and "signature only" (cf. Section 3.2): 473 Sending and receiving sides MUST implement the "signature and 474 encryption" Protection Level, which SHOULD be used as default on the 475 sending side. 477 Certain implementations may decide to send "signature only" Messages, 478 depending on the circumstances and customer requirements. Sending 479 sides MAY and receiving sides MUST implement "signature only" 480 Protection Level. 482 It generally is NOT RECOMMENDED to send a Message with any other 483 Protection Level. On the other hand, the receiving side must be 484 prepared to receive Messages with other Protection Levels. 486 [[ TODO: Further study is necessary to determine whether - and if yes 487 to what extent - additional guidance for handling messages with other 488 Protection Levels, e.g. "encryption only" at the receiving side 489 should be included in this document. ]] 491 4.1. Main Use Case 493 This section applies to the main use case, where the sending and 494 receiving side (fully) support Header Protection as specified herein 495 (cf. Section 3.1.1). 497 Note: The sending side specification of the main use case is also 498 applicable to the cases where the sending side (fully) supports 499 Header Protection as specified herein, while the receiving side does 500 not, but is MIME-conformant according to [RFC2045], ff. (cf. 501 Section 3.1.2 and Section 3.1.2.1). 503 Further backward compatibility cases are defined in Section 4.2. 505 4.1.1. MIME Format 507 4.1.1.1. Introduction 509 As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending 510 client MAY wrap a full MIME message in a message/RFC822 wrapper in 511 order to apply S/MIME security services to these header fields. 513 To help the receiving side to distinguish between a forwarded and a 514 wrapped message, the Content-Type header field parameter "forwarded" 515 is added as defined in [I-D.melnikov-iana-reg-forwarded]. 517 The simplified (cryptographic overhead not shown) MIME structure of 518 such an Email Message looks as follows: 520 522 524 526 528 530 The following example demonstrates how an Original Message might be 531 protected, i.e., the Original Message is contained as Inner Message 532 in the Protected Body of an Outer Message. It illustrates the first 533 Body part (of the Outer Message) as a "multipart/signed" 534 (application/pkcs7-signature) media type: 536 Lines are prepended as follows: 538 * "O: " Outer Message Header Section 540 * "I: " Message Header Section 542 * "W: " Wrapper (MIME Header Section) 543 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 544 O: Message-ID: 545 O: Subject: Meeting at my place 546 O: From: "Alexey Melnikov" 547 O: To: somebody@example.net 548 O: MIME-Version: 1.0 549 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 550 O: protocol="application/pkcs7-signature"; 551 O: boundary=boundary-AM 553 This is a multipart message in MIME format. 554 --boundary-AM 555 W: Content-Type: message/RFC822; forwarded=no 556 W: 557 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 558 I: From: "Alexey Melnikov" 559 I: Message-ID: 560 I: MIME-Version: 1.0 561 I: MMHS-Primary-Precedence: 3 562 I: Subject: Meeting at my place 563 I: To: somebody@example.net 564 I: X-Mailer: Isode Harrier Web Server 565 I: Content-Type: text/plain; charset=us-ascii 567 This is an important message that I don't want to be modified. 569 --boundary-AM 570 Content-Transfer-Encoding: base64 571 Content-Type: application/pkcs7-signature 573 [[base-64 encoded signature]] 575 --boundary-AM-- 577 The Outer Message Header Section is unprotected, while the remainder 578 (Outer Message Body) is protected. The Outer Message Body consists 579 of the wrapper (MIME Header Section) and the Inner Message (Header 580 Section and Body). 582 The wrapper is a simple MIME Header Section with media type "message/ 583 rfc822" containing a Content-Type header field parameter 584 "forwarded=no" followed by an empty line. 586 If the source is an Original (message/rfc822) Message, the Inner 587 Message Header Section is typically the same as (or a subset of) the 588 Original Message Header Section (cf. Section 4.1.2.1), and the Inner 589 Message Body is typically the same as the Original Message Body. 591 The Inner Message itself may contain any MIME structure. 593 Note: It is still to be decided by the LAMPS WG whether or not to 594 recommend an alternative MIME format as described in Appendix B.1.1.1 595 (instead of the currently standardized and above defined format). 597 4.1.2. Sending Side 599 To ease explanation, the following describes the case where an 600 Original (message/rfc822) Message to be protected is present. If 601 this is not the case, Original Message means the (virtual) Message 602 that would be constructed for sending it as unprotected email. 604 4.1.2.1. Inner Message Header Fields 606 It is RECOMMENDED that the Inner Message contains all Header Fields 607 of the Original Message with the exception of the following Header 608 Field, which MUST NOT be included within the Inner Message nor within 609 any other protected part of the Message: 611 * Bcc 613 [[ TODO: Bcc handling needs to be further specified (see also 614 Appendix A.1). Certain MUAs cannot properly decrypt Messages with 615 Bcc recipients. ]] 617 4.1.2.2. Wrapper 619 The wrapper is a simple MIME Header Section followed by an empty line 620 preceding the Inner Message (inside the Outer Message Body). The 621 media type of the wrapper MUST be "message/RFC822" and MUST contain 622 the Content-Type header field parameter "forwarded=no" as defined in 623 [I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously 624 delimits the Inner Message from the rest of the Message. 626 4.1.2.3. Cryptographic Layers / Envelope 628 [[ TODO: Basically refer to S/MIME standards ]] 630 4.1.2.4. Outer Message Header Fields 632 4.1.2.4.1. Encrypted Messages 634 To maximize Privacy, it is strongly RECOMMENDED to follow the 635 principle of Data Minimization (cf. Section 2.1). 637 However, the Outer Message Header Section SHOULD contain the 638 Essential Header Fields and, in addition, MUST contain the Header 639 Fields of the MIME Header Section part to describe Cryptographic 640 Layer of the protected MIME subtree as per [RFC8551]. 642 The following Header Fields are defined as the Essential Header 643 Fields: 645 * From 647 * To (if present in the Original Message) 649 * Cc (if present in the Original Message) 651 * Bcc (if present in the Original Message, see also Section 4.1.2.1 652 and Appendix A.1) 654 * Date 656 * Message-ID 658 * Subject 660 Further processing by the Submission Entity normally depends on part 661 of these Header Fields, e.g. From and Date HFs are required by 662 [RFC5322]. Furthermore, not including certain Header Fields may 663 trigger spam detection to flag the Message, and/or lead to user 664 experience (UX) issues. 666 For further Data Minimization, the value of the Subject Header Field 667 SHOULD be obfuscated as follows: 669 * Subject: [...] 671 and it is RECOMMENDED to replace the Message-ID by a new randomly 672 generated Message-ID. 674 In addition, the value of other Essential Header Fields MAY be 675 obfuscated. 677 Non-Essential Header Fields SHOULD be omitted from the Outer Message 678 Header Section where possible. If Non-essential Header Fields are 679 included in the Outer Message Header Section, those MAY be obfuscated 680 too. 682 Header Fields that are not obfuscated should contain the same values 683 as in the Original Message. 685 If an implementation obfuscates the From, To, and/or Cc Header 686 Fields, it may need to provide access to the clear text content of 687 these Header Fields to the Submission Entity for processing purposes. 688 This is particularly relevant, if proprietary Submission Entities are 689 used. Obfuscation of Header Fields may adversely impact spam 690 filtering. 692 (A use case for obfuscation of all Outer Message Header Fields is 693 routing email through the use of onion routing or mix networks, e.g. 694 [pEp.mixnet].) 696 The MIME Header Section part is the collection of MIME Header Fields 697 describing the following MIME structure as defined in [RFC2045]. A 698 MIME Header Section part typically includes the following Header 699 Fields: 701 * Content-Type 703 * Content-Transfer-Encoding 705 * Content-Disposition 707 The following example shows the MIME Header Section part of an S/MIME 708 signed Message (using application/pkcs7-mime with SignedData): 710 MIME-Version: 1.0 711 Content-Type: application/pkcs7-mime; smime-type=signed-data; 712 name=smime.p7m 713 Content-Transfer-Encoding: base64 714 Content-Disposition: attachment; filename=smime.p7m 716 Depending on the scenario, further Header Fields MAY be exposed in 717 the Outer Message Header Section, which is NOT RECOMMENDED unless 718 justified. Such Header Fields may include e.g.: 720 * References 722 * Reply-To 724 * In-Reply-To 726 4.1.2.4.2. Unencrypted Messages 728 The Outer Message Header Section of unencrypted Messages SHOULD 729 contain at least the Essential Header Fields and, in addition, MUST 730 contain the Header Fields of the MIME Header Section part to describe 731 Cryptographic Layer of the protected MIME subtree as per [RFC8551]. 732 It may contain further Header Fields, in particular those also 733 present in the Inner Message Header Section. 735 4.1.2.5. Sending Side Message Processing 737 For a protected Message the following steps are applied before a 738 Message is handed over to the Submission Entity: 740 4.1.2.5.1. Step 1: Decide on Protection Level and Information 741 Disclosure 743 The implementation which applies protection to a Message must decide: 745 * Which Protection Level (signature and/or encryption) shall be 746 applied to the Message? This depends on user request and/or local 747 policy as well as availability of cryptographic keys. 749 * Which Header Fields of the Original Message shall be part of the 750 Outer Message Header Section? This typically depends on local 751 policy. By default, the Essential Header Fields are part of the 752 Outer Message Header Section; cf. Section 4.1.2.4. 754 * Which of these Header Fields are to be obfuscated? This depends 755 on local policy and/or specific Privacy requirements of the user. 756 By default only the Subject Header Field is obfuscated; cf. 757 Section 4.1.2.4. 759 4.1.2.5.2. Step 2: Compose the Outer Message Header Section 761 Depending on the decision in Section 4.1.2.5.1, the implementation 762 shall compose the Outer Message Header Section. (Note that this also 763 includes the necessary MIME Header Section part for the following 764 protection layer.) 766 Outer Header Fields that are not obfuscated should contain the same 767 values as in the Original Message (except for MIME Header 768 Section part, which depends on the Protection Level selected in 769 Section 4.1.2.5.1). 771 4.1.2.5.3. Step 3: Apply Protection to the Original Message 773 Depending on the Protection Level selected in Section 4.1.2.5.1, the 774 implementation applies signature and/or encryption to the Original 775 Message, including the wrapper (as per [RFC8551]), and sets the 776 resulting package as the Outer Message Body. 778 The resulting (Outer) Message is then typically handed over to the 779 Submission Entity. 781 [[ TODO: Example ]] 783 4.1.3. Receiving Side 785 4.1.3.1. Receiving User Facing Message Header Fields 787 The Receiving User Facing Message SHOULD be a verbatim copy of the 788 Inner Message. 790 4.1.3.2. Receiving Side Message Processing 792 When a protected Message is received, the following steps are 793 applied: 795 4.1.3.2.1. Step 1: Decrypt Message and/or check signature 797 Depending on the Protection Level, the received Message is decrypted 798 and/or its signature is checked as per [RFC8551]. 800 4.1.3.2.2. Step 2: Construct the Receiving User Facing Message 802 The Receiving User Facing Message is constructed according to 803 Section 4.1.3.1. 805 The resulting Message is handed over for further processing, which 806 typically involves rendering it for the user. 808 4.1.3.3. Step 3: Prepare Information Cyptographic Verification 810 [[ TODO: Signature valid, etc. ]] 812 4.2. Backward Compatibility Use Cases 814 4.2.1. Receiving Side MIME-Conformant 816 This section applies to the case where the sending side (fully) 817 supports Header Protection as specified in this document, while the 818 receiving side does not support this specification, but is MIME- 819 conformant according to [RFC2045], ff. (cf. Section 3.1.2 and 820 Section 3.1.2.1) 822 The sending side specification of the main use case (cf. 823 Section 4.1) MUST ensure that receiving sides can still recognize and 824 display or offer to display the encapsulated data in accordance with 825 its media type (cf. [RFC2049], Section 2). In particular, receiving 826 sides that do not support this specification, but are MIME-conformant 827 according to [RFC2045], ff. can still recognize and display the 828 Message intended for the user. 830 [[ TODO: Verify once solution is stable and update last sentence. ]] 832 4.2.2. Receiving Side Not MIME-Conformant 834 This section applies to cases where the sending side (fully) supports 835 Header Protection as specified in this document, while the receiving 836 side neither supports this specification *nor* is MIME-conformant 837 according to [RFC2045], ff. (cf. Section 3.1.2 and Section 3.1.2.2). 839 [I-D.autocrypt-lamps-protected-headers] describes a possible way to 840 achieve backward compatibility with existing S/MIME (and PGP/MIME) 841 implementations that predate this specification and are not MIME- 842 conformant (Legacy Display) either. It mainly focuses on email 843 clients that do not render emails which utilize header protection in 844 a user friendly manner, which may confuse the user. While this has 845 been observed occasionally in PGP/MIME (cf. [RFC3156]), the extent 846 of this problem with S/MIME implementations is still unclear. (Note: 847 At this time, none of the samples in 848 [I-D.autocrypt-lamps-protected-headers] apply header protection as 849 specified in Section 3.1 of [RFC8551], which is wrapping as Media 850 Type "message/RFC822".) 852 Should serious backward compatibility issues with rendering at the 853 receiving side be discovered, the Legacy Display format described in 854 [I-D.autocrypt-lamps-protected-headers] may serve as a basis to 855 mitigate those issues (cf. Section 4.2). 857 Another variant of backward compatibility has been implemented by pEp 858 [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has 859 implemented this for PGP/MIME, but not yet S/MIME. 861 5. Security Considerations 863 [[ TODO ]] 865 6. Privacy Considerations 867 [[ TODO ]] 869 7. IANA Considerations 871 This document requests no action from IANA. 873 [[ RFC Editor: This section may be removed before publication. ]] 875 8. Acknowledgments 877 The authors would like to thank the following people who have 878 provided helpful comments and suggestions for this document: Berna 879 Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista 880 Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ 881 Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. 883 9. References 885 9.1. Normative References 887 [I-D.dkg-lamps-e2e-mail-guidance] 888 Gillmor, D., "Guidance on End-to-End E-mail Security", 889 Work in Progress, Internet-Draft, draft-dkg-lamps-e2e- 890 mail-guidance-00, 31 October 2020, . 893 [I-D.ietf-lamps-header-protection-requirements] 894 Melnikov, A. and B. Hoeneisen, "Problem Statement and 895 Requirements for Header Protection", Work in Progress, 896 Internet-Draft, draft-ietf-lamps-header-protection- 897 requirements-01, 29 October 2019, . 901 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 902 Extensions (MIME) Part One: Format of Internet Message 903 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 904 . 906 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 907 Extensions (MIME) Part Two: Media Types", RFC 2046, 908 DOI 10.17487/RFC2046, November 1996, 909 . 911 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 912 Extensions (MIME) Part Five: Conformance Criteria and 913 Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, 914 . 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, 918 DOI 10.17487/RFC2119, March 1997, 919 . 921 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 922 DOI 10.17487/RFC5322, October 2008, 923 . 925 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 926 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 927 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 928 April 2019, . 930 9.2. Informative References 932 [I-D.autocrypt-lamps-protected-headers] 933 Einarsson, B., juga, j., and D. Gillmor, "Protected 934 Headers for Cryptographic E-mail", Work in Progress, 935 Internet-Draft, draft-autocrypt-lamps-protected-headers- 936 02, 20 December 2019, . 939 [I-D.melnikov-iana-reg-forwarded] 940 Melnikov, A. and B. Hoeneisen, "IANA Registration of 941 Content-Type Header Field Parameter 'forwarded'", Work in 942 Progress, Internet-Draft, draft-melnikov-iana-reg- 943 forwarded-00, 4 November 2019, . 946 [I-D.pep-email] 947 Marques, H., "pretty Easy privacy (pEp): Email Formats and 948 Protocols", Work in Progress, Internet-Draft, draft-pep- 949 email-00, 10 July 2020, . 952 [pEp.mixnet] 953 pEp Foundation, "Mixnet", June 2020, 954 . 956 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 957 "MIME Security with OpenPGP", RFC 3156, 958 DOI 10.17487/RFC3156, August 2001, 959 . 961 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 962 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 963 . 965 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 966 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 967 RFC 6376, DOI 10.17487/RFC6376, September 2011, 968 . 970 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 971 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 972 . 974 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 975 Message Authentication, Reporting, and Conformance 976 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 977 . 979 Appendix A. Additional information 981 A.1. Stored Variants of Messages with Bcc 983 Messages containing at least one recipient address in the Bcc header 984 field may appear in up to three different variants: 986 1. The Message for the recipient addresses listed in To or Cc header 987 fields, which must not include the Bcc header field neither for 988 signature calculation nor for encryption. 990 2. The Message(s) sent to the recipient addresses in the Bcc header 991 field, which depends on the implementation: 993 a) One Message for each recipient in the Bcc header field 994 separately, with a Bcc header field containing only the address 995 of the recipient it is sent to. 997 b) The same Message for each recipient in the Bcc header field 998 with a Bcc header field containing an indication such as 999 "Undisclosed recipients", but no addresses. 1001 c) The same Message for each recipient in the Bcc header field 1002 which does not include a Bcc header field (this Message is 1003 identical to 1. / cf. above). 1005 3. The Message stored in the 'Sent'-Folder of the sender, which 1006 usually contains the Bcc unchanged from the original Message, 1007 i.e., with all recipient addresses. 1009 The most privacy preserving method of the alternatives (2a, 2b, and 1010 2c) is to standardize 2a, as in the other cases (2b and 2c), 1011 information about hidden recipients is revealed via keys. In any 1012 case, the Message has to be cloned and adjusted depending on the 1013 recipient. 1015 Appendix B. Text Moved from Above 1017 Note: Per an explicit request by the chair of the LAMPS WG to only 1018 present one option for the specification, the following text has been 1019 stripped from the main body of the draft. It is preserved in an 1020 Appendix for the time being and may be moved back to the main body or 1021 deleted, depending on the decision of the LAMPS WG. 1023 B.1. MIME Format 1025 Currently there are two options in discussion: 1027 1. The option according to the current S/MIME specification (cf. 1028 [RFC8551]) 1030 2. An alternative option that is based on the former "memory hole" 1031 approach (cf. [I-D.autocrypt-lamps-protected-headers]) 1033 B.1.1. S/MIME Specification 1035 Note: This is currently described in the main part of this document. 1037 B.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory 1038 Hole") 1040 An alternative option (based on the former autocrypt "Memory Hole" 1041 approach) to be considered, is described in 1042 [I-D.autocrypt-lamps-protected-headers]. 1044 Unlike the option described in Appendix B.1.1, this option does not 1045 use a "message/RFC822" wrapper to unambiguously delimit the Inner 1046 Message. 1048 Before choosing this option, the following two issues must be 1049 assessed to ensure no interoperability issues result from it: 1051 1. How current MIME parser implementations treat non-MIME Header 1052 Fields, which are not part of the outermost MIME entity and not 1053 part of a Message wrapped into a MIME entity of media type 1054 "message/rfc822", and how such Messages are rendered to the user. 1056 [I-D.autocrypt-lamps-protected-headers] provides some examples 1057 for testing this. 1059 2. MIME-conformance, i.e. whether or not this option is (fully) 1060 MIME-conformant [RFC2045] ff., in particular also Section 5.1. of 1061 [RFC2046] on "Multipart Media Type). In the following an excerpt 1062 of paragraphs that may be relevant in this context: 1064 The only header fields that have defined meaning for body parts 1065 are those the names of which begin with "Content-". All other 1066 header fields may be ignored in body parts. Although they 1067 should generally be retained if at all possible, they may be 1068 discarded by gateways if necessary. Such other fields are 1069 permitted to appear in body parts but must not be depended on. 1070 "X-" fields may be created for experimental or private 1071 purposes, with the recognition that the information they 1072 contain may be lost at some gateways. 1074 NOTE: The distinction between an RFC 822 Message and a body 1075 part is subtle, but important. A gateway between Internet and 1076 X.400 mail, for example, must be able to tell the difference 1077 between a body part that contains an image and a body part 1078 that contains an encapsulated Message, the body of which is a 1079 JPEG image. In order to represent the latter, the body part 1080 must have "Content-Type: message/rfc822", and its body (after 1081 the blank line) must be the encapsulated Message, with its own 1082 "Content-Type: image/jpeg" header field. The use of similar 1083 syntax facilitates the conversion of Messages to body parts, 1084 and vice versa, but the distinction between the two must be 1085 understood by implementors. (For the special case in which 1086 parts actually are Messages, a "digest" subtype is also 1087 defined.) 1089 The MIME structure of an Email Message looks as follows: 1091 1093 1095 1097 1099 The following example demonstrates how an Original Message might be 1100 protected, i.e., the Original Message is contained as Inner Message 1101 in the Protected Body of an Outer Message. It illustrates the first 1102 Body part (of the Outer Message) as a "multipart/signed" 1103 (application/pkcs7-signature) media type: 1105 Lines are prepended as follows: 1107 * "O: " Outer Message Header Section 1109 * "I: " Message Header Section 1110 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 1111 O: Message-ID: 1112 O: Subject: Meeting at my place 1113 O: From: "Alexey Melnikov" 1114 O: MIME-Version: 1.0 1115 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 1116 O: protocol="application/pkcs7-signature"; 1117 O: boundary=boundary-AM 1119 This is a multipart message in MIME format. 1120 --boundary-AM 1121 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 1122 I: From: "Alexey Melnikov" 1123 I: Message-ID: 1124 I: MIME-Version: 1.0 1125 I: MMHS-Primary-Precedence: 3 1126 I: Subject: Meeting at my place 1127 I: To: somebody@example.net 1128 I: X-Mailer: Isode Harrier Web Server 1129 I: Content-Type: text/plain; charset=us-ascii 1131 This is an important message that I don't want to be modified. 1133 --boundary-AM 1134 Content-Transfer-Encoding: base64 1135 Content-Type: application/pkcs7-signature 1137 [[base-64 encoded signature]] 1139 --boundary-AM-- 1141 The Outer Message Header Section is unprotected, while the remainder 1142 (Outer Message Body) is protected. The Outer Message Body consists 1143 of the Inner Message (Header Section and Body). 1145 The Inner Message Header Section is the same as (or a subset of) the 1146 Original Message Header Section (cf. Section 4.1.2.1). 1148 The Inner Message Body is the same as the Original Message Body. 1150 The Original Message itself may contain any MIME structure. 1152 Appendix C. Document Changelog 1154 [[ RFC Editor: This section is to be removed before publication ]] 1156 * draft-ietf-lamps-header-protection-02 1157 - editorial changes / improve language 1159 * draft-ietf-lamps-header-protection-01 1161 - Add DKG as co-author 1163 - Partial Rewrite of Abstract and Introduction [HB/AM/DKG] 1165 - Adding definiations for Cryptographic Layer, Cryptographic 1166 Payload, and Cryptographic Envelope (reference to 1167 [I-D.dkg-lamps-e2e-mail-guidance]) [DKG] 1169 - Enhanced MITM Definition to include Machine- / Meddler-in-the- 1170 middle [HB] 1172 - Relaxed definition of Original message, which may not be of 1173 type "message/rfc822" [HB] 1175 - Move "memory hole" option to the Appendix (on request by Chair 1176 to only maintain one option in the specification) [HB] 1178 - Updated Scope of Protection Levels according to WG discussion 1179 during IETF-108 [HB] 1181 - Obfuscation recommendation only for Subject and Message-Id and 1182 distinguish between Encrypted and Unencrypted Messages [HB] 1184 - Removed (commented out) Header Field Flow Figure (it appeared 1185 to be confusing as is was) [HB] 1187 * draft-ietf-lamps-header-protection-00 1189 - Initial version (text partially taken over from 1190 [I-D.ietf-lamps-header-protection-requirements] 1192 Appendix D. Open Issues 1194 [[ RFC Editor: This section should be empty and is to be removed 1195 before publication. ]] 1197 * Ensure "protected header" (Ex-Memory-Hole) option is (fully) 1198 compliant with the MIME standard, in particular also [RFC2046], 1199 Section 5.1. (Multipart Media Type) Appendix B.1.1.1. 1201 * More examples (e.g. in Section 4.1.2.5) 1203 * Should Outer Message Header Section (as received) be preserved for 1204 the user? (Section 4.1.3.2.2) 1206 * Decide on whether or not merge requirements from 1207 [I-D.ietf-lamps-header-protection-requirements] into this 1208 document. 1210 * Decide what parts of [I-D.autocrypt-lamps-protected-headers] to 1211 merge into this document. 1213 * Enhance Introduction Section 1 and Problem Statement (Section 2). 1215 * Decide on whether or not specification for more legacy HP 1216 requirements should be added to this document (Section 3.1.2). 1218 * Verify simple backward compatibility case (Receiving Side MIME- 1219 Conformant) is working; once solution is stable and update 1220 paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1 1221 accordingly. 1223 * Verify ability to distinguish between Messages with Header 1224 Protection as specified in this document and legacy clients and 1225 update Section 3.1 accordingly. 1227 * Improve definitions of Protection Levels and enhance list of 1228 Protection Levels (Section 3.2, Section 4). 1230 * Privacy Considerations Section 6 1232 * Security Considerations Section 5 1234 Authors' Addresses 1236 Bernie Hoeneisen 1237 pEp Foundation 1238 Oberer Graben 4 1239 CH- CH-8400 Winterthur 1240 Switzerland 1242 Email: bernie.hoeneisen@pep.foundation 1243 URI: https://pep.foundation/ 1245 Daniel Kahn Gillmor 1246 American Civil Liberties Union 1247 125 Broad St. 1248 New York, NY, 10004 1249 United States of America 1251 Email: dkg@fifthhorseman.net 1252 Alexey Melnikov 1253 Isode Ltd 1254 14 Castle Mews 1255 Hampton, Middlesex 1256 TW12 2NP 1257 United Kingdom 1259 Email: alexey.melnikov@isode.com