idnits 2.17.1 draft-ietf-lamps-header-protection-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 13, 2020) is 1375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-pep-email-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Hoeneisen 3 Internet-Draft pEp Foundation 4 Intended status: Informational A. Melnikov 5 Expires: January 14, 2021 Isode Ltd 6 July 13, 2020 8 Header Protection for S/MIME 9 draft-ietf-lamps-header-protection-00 11 Abstract 13 Privacy and security issues with email header protection in S/MIME 14 have been identified for some time. However, the desire to fix these 15 issues has only recently been expressed in the IETF LAMPS Working 16 Group. The existing S/MIME specification is to be updated regarding 17 header protection. 19 This document describes the problem statement, generic use cases, and 20 the S/MIME specification for header protection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 7 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 7 67 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 7 68 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 9 69 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 10 72 4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 15 73 4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 16 75 4.1.5. Receiving User Facing Message Header Fields . . . . . 18 76 4.1.6. Header Field Flow . . . . . . . . . . . . . . . . . . 18 77 4.1.7. Sending Side Message Processing . . . . . . . . . . . 20 78 4.1.8. Receiving Side Message Processing . . . . . . . . . . 21 79 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 21 80 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 21 81 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 22 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 9.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Appendix A. Additional information . . . . . . . . . . . . . . . 25 90 A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 25 91 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 26 92 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 26 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction 97 A range of protocols for the protection of electronic mail (email) 98 exists, which allows to assess the authenticity and integrity of the 99 email headers section or selected header fields (HF) from the domain- 100 level perspective, specifically DomainKeys Identified Mail (DKIM) 101 [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain- 102 based Message Authentication, Reporting, and Conformance (DMARC) 103 [RFC7489]. These protocols, while essential to responding to a range 104 of attacks on email, do not offer (full) end-to-end protection to the 105 header section and are not capable of providing privacy for the 106 information contained therein. 108 The need for means of Data Minimization, which includes data 109 sparseness and hiding all technically concealable information 110 whenever possible, has grown in importance over the past several 111 years. 113 A standard for end-to-end protection of the email header section 114 exists for S/MIME version 3.1 and later. (cf. [RFC8551]): 116 In order to protect outer, non-content-related message header 117 fields (for instance, the "Subject", "To", "From", and "Cc" 118 fields), the sending client MAY wrap a full MIME message in a 119 message/RFC822 wrapper in order to apply S/MIME security services 120 to these header fields. 122 No mechanism for header protection (HP) has been standardized for 123 PGP/MIME (Pretty Good Privacy) [RFC3156] yet. 125 Several varying implementations of end-to-end protections for email 126 header sections exist, though the total number of such 127 implementations appears to be rather low. 129 Some LAMPS WG participants expressed the opinion that regardless of 130 the mechanism chosen, it should not be limited to S/MIME, but also 131 applicable to PGP/MIME. 133 This document describes the problem statement (Section 2), generic 134 use cases (Section 3) and the specification for Header Protection 135 (Section 4). 137 [I-D.ietf-lamps-header-protection-requirements] defines the 138 requirements that this specification is based on. 140 This document is in early draft state and contains a proposal on 141 which to base future discussions of this topic. In any case, the 142 final mechanism is to be determined by the IETF LAMPS WG. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 1.2. Terms 152 The following terms are defined for the scope of this document: 154 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 155 form of active wiretapping attack in which the attacker intercepts 156 and selectively modifies communicated data to masquerade as one or 157 more of the entities involved in a communication association." 159 o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. 160 [RFC8551]) 162 o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) 164 o Message: An Email Message consisting of Header Fields 165 (collectively called "the Header Section of the message") 166 followed, optionally, by a Body; cf. [RFC5322]. 168 Note: To avoid ambiguity, this document does not use the terms 169 "Header" or "Headers" in isolation, but instead always uses 170 "Header Field" to refer to the individual field and "Header 171 Section" to refer to the entire collection; cf. [RFC5322]. 173 o Header Field (HF): cf. [RFC5322] Header Fields are lines beginning 174 with a field name, followed by a colon (":"), followed by a field 175 body (value), and terminated by CRLF; cf. [RFC5322]. 177 o Header Section (HS): The Header Section is a sequence of lines of 178 characters with special syntax as defined in [RFC5322]. It is the 179 (top) section of a Message containing the Header Fields. 181 o Body: The Body is simply a sequence of characters that follows the 182 Header Section and is separated from the Header Section by an 183 empty line (i.e., a line with nothing preceding the CRLF); cf 184 [RFC5322]. It is the (bottom) section of Message containing the 185 payload of a Message. Typically, the Body consists of a (possibly 186 multipart) MIME [RFC2045] construct. 188 o MIME Header Fields: Header Fields describing content of a MIME 189 entity [RFC2045], in particular the MIME structure. Each MIME 190 Header Field name starts with "Content-" prefix. 192 o MIME Header Section (part): The collection of MIME Header Fields. 193 "MIME Header Section" refers to a Header Sections that contains 194 only MIME Header Fields, whereas "MIME Header Section part" refers 195 to the MIME Header Fields of a Header Section that - in addition 196 to MIME Header Fields - also contains non-MIME Header Fields. 198 o Essential Header Fields (EHF): The minimum set of Header Fields an 199 Outer Message Header Section SHOULD contain; cf. Section 4.1.4. 201 o Header Protection (HP): cryptographic protection of email Header 202 Sections (or parts of it) for signatures and/or encryption 204 o Protection Levels (PL): One of 'signature and encryption', 205 'signature only' or 'encryption only' (cf. Section 3.2) 207 o Protected: Protected refers to the parts of a Message where 208 protection measures of any Protection Level have been applied to. 210 o Protected Message: A Message that protection measures of any 211 Protection Levels have been applied to. 213 o Unprotected: Unprotected refers to the parts of a Message where no 214 protection measures of any Protection Levels have been applied to. 216 o Unprotected Message: A Message that no protection measures of any 217 Protection Levels have been applied to. 219 o Submission Entity: The entity taking care of further processing of 220 the Message (incl. transport towards the receiver), after 221 protection measures have been applied to. 223 Note: The Submission Entity varies among implementations, mainly 224 depending on the stage, where protection measures are applied to: 225 It could be e.g. a Message Submission Agent (MSA) [RFC6409] or 226 another (proprietary) solution. The latter is particularly 227 relevant, if protection is implemented as a plugin solution. Some 228 implementations may determine the destination recipients by 229 reading the To, Cc and Bcc Header Fields of the Outer Message. 231 o Original Message (OrigM): The message to be protected before any 232 protection related processing has been applied on the sending 233 side. 235 o Inner Message (InnerM): The message to be protected, i.e. which 236 wrapping and protection measures are applied to on the sending 237 side or the result of decryption and unwrapping on the receiving 238 side respectively. Typically, the Inner Message is in clear text. 239 The Inner Message is a subset of (or the same as) the Original 240 Message (cf. Section 4.1.2). The Inner Message must be the same 241 on the sending and the receiving side. 243 o Outer Message (OuterM): The Message as handed over to the 244 Submission Entity or received from the last hop respectively. The 245 Outer Message normally differs on the sending and the receiving 246 side (e.g. new Header Fields are added by intermediary nodes). 248 o Receiving User Facing Message (RUFM): The message used for 249 rendering at the receiving side. Typically this is the same as 250 the Inner Message. 252 o Data Minimization: Data sparseness and hiding of all technically 253 concealable information whenever possible. 255 2. Problem Statement 257 The LAMPS charter contains the following Work Item: 259 Update the specification for the cryptographic protection of email 260 headers - both for signatures and encryption - to improve the 261 implementation situation with respect to privacy, security, 262 usability and interoperability in cryptographically-protected 263 electronic mail. Most current implementations of 264 cryptographically-protected electronic mail protect only the body 265 of the message, which leaves significant room for attacks against 266 otherwise-protected messages. 268 In the following a set of challenges to be addressed: 270 [[ TODO: Enhance this section, add more items to the following. ]] 272 2.1. Privacy 274 o Data Minimization, which includes data sparseness and hiding all 275 technically concealable information whenever possible 277 2.2. Security 279 o MITM attacks (cf. [RFC4949]) 281 2.3. Usability 283 o User interaction / User experience 285 2.4. Interoperability 287 o Interoperability with [RFC8551] implementations 289 3. Use Cases 291 In the following, the reader can find a list of the generic use cases 292 that need to be addressed for Messages with Header Protection (HP). 293 These use cases apply regardless of technology (S/MIME, PGP/MIME, 294 etc.) used to achieve HP. 296 3.1. Interactions 298 The following use cases assume that at least the sending side 299 supports Header Protection as specified in this document. Receiving 300 sides that support this specification are expected to be able to 301 distinguish between Messages that Header Protection - as specified in 302 this document - has been applied to and (legacy) Mail User Agents 303 (MUAs) not implementing this specification. 305 [[ TODO: Verify once solution is stable and update last sentence. ]] 307 3.1.1. Main Use Case 309 Both the sending and receiving side (fully) support Header Protection 310 as specified in this document. 312 The main use case is specified in Section 4.1. 314 3.1.2. Backward Compatibility Use Cases 316 Regarding backward compatibility, the main distinction is based on 317 whether or not the receiving side conforms to MIME according to 318 [RFC2046], ff., which in particular also includes Section 2 of 319 [RFC2049] on "MIME Conformance". In the following an excerpt of 320 paragraphs relevant in this context: 322 A mail user agent that is MIME-conformant MUST: 324 [...] 326 -- Recognize and display at least the RFC822 message 327 encapsulation (message/rfc822) in such a way as to 328 preserve any recursive structure, that is, displaying 329 or offering to display the encapsulated data in 330 accordance with its media type. 332 -- Treat any unrecognized subtypes as if they were 333 "application/octet-stream". 335 [...] 337 A user agent that meets the above conditions is said to be MIME- 338 conformant. The meaning of this phrase is that it is assumed to be 339 "safe" to send virtually any kind of properly-marked data to users 340 of such mail systems, because such systems will at least be able to 341 treat the data as undifferentiated binary, and will not simply 342 splash it onto the screen of unsuspecting users. 344 [[ TODO: The compatibility of legacy HP systems with this new 345 solution, and how to handle issues surrounding future maintenance for 346 these legacy systems, will be decided by the LAMPS WG. ]] 348 3.1.2.1. Receiving Side MIME-Conformant 350 The sending side (fully) supports Header Protection as specified in 351 this document, while the receiving side does not support this 352 specification. However, the receiving side is MIME-conformant 353 according to [RFC2045], ff. (cf. Section 3.1.2), 355 This use case is specified in Section 4.2.1. 357 Note: This case should perform as expected if the sending side 358 applies this specification as outlined in Section 4.1. 360 [[ TODO: Verify once solution is stable and update last sentence. ]] 362 3.1.2.2. Receiving Side Not MIME-Conformant 364 The sending side (fully) supports Header Protection as specified in 365 this document, while the receiving side does not support this 366 specification. Furthermore, the receiving side is *not* MIME- 367 conformant according to [RFC2045], ff. (cf. Section 3.1.2). 369 This use case is specified in Section 4.2.2. 371 3.2. Protection Levels 373 The following Protection Levels need to be considered: 375 a) Signature and encryption 377 Messages containing a cryptographic signature, which are also 378 encrypted. 380 b) Signature only 382 Messages containing a cryptographic signature, but which are not 383 encrypted. 385 c) Encryption only 387 Messages that are encrypted, but do not contain a cryptographic 388 signature. 390 [[ TODO: There are further "Protection Levels" to describe for the 391 receiving side, e.g. encrypted and signed (only after encryption), 392 etc. ]] 394 4. Specification 396 This section contains the specification for Header Protection in 397 S/MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0). 399 Note: It is likely that PGP/MIME [RFC3156] will also incorporate this 400 specification or parts of it. 402 This specification applies to the Protection Levels "signature & 403 encryption" and "signature only" (cf. Section 3.2): 405 Sending and receiving sides MUST implement the "signature and 406 encryption" Protection Level", which SHOULD be used as default on the 407 sending side. 409 Certain implementations may decide to send "signature only" messages, 410 depending on the circumstances and customer requirements. Sending 411 sides MAY and receiving sides MUST implement "signature only" 412 Protection Level. 414 It generally is NOT RECOMMENDED to send a message with Protection 415 Level "encryption only". On the other hand, messages with Protection 416 Level "encryption only" might arrive at the receiving side. While 417 not targeted to Protection Level "encryption only", this 418 specification is assumed to also function for "encryption only". 419 Receiving sides SHOULD implement "encryption only". 421 [[ TODO: Further study is necessary to determine whether - and if yes 422 to what extent - additional guidance for handling messages with 423 "encryption only" protection (as well as other variations) at the 424 receiving side should be included in this document. ]] 426 4.1. Main Use Case 428 This section applies to the main use case, where the sending and 429 receiving side (fully) support Header Protection as specified herein 430 (cf. Section 3.1.1). 432 Note: The sending side specification of the main use case is also 433 applicable to the cases where the sending side (fully) supports 434 Header Protection as specified herein, while the receiving side does 435 not, but is MIME-conformant according to [RFC2045], ff. (cf. 436 Section 3.1.2) and Section 3.1.2.1) 438 Further backward compatibility cases are defined in Section 4.2. 440 4.1.1. MIME Format 442 Currently there are two options in discussion: 444 1. The option according to the current S/MIME specification (cf. 445 [RFC8551]) 447 2. An alternative option that is based on the former "memory hole" 448 approach (cf. [I-D.autocrypt-lamps-protected-headers]) 450 4.1.1.1. S/MIME Specification 452 As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending 453 client MAY wrap a full MIME message in a message/RFC822 wrapper in 454 order to apply S/MIME security services to these header fields. 456 To help the receiving side to distinguish between a forwarded and a 457 wrapped message, the Content-Type header field parameter "forwarded" 458 is added as defined in [I-D.melnikov-iana-reg-forwarded]. Certain 459 mailing applications might display the Inner Message as an attachment 460 otherwise. 462 The MIME structure of an Email message looks as follows: 464 466 468 470 472 474 The following example demonstrates how an Original Message might be 475 protected, i.e., the Original Message is contained as Inner Message 476 in the Protected Body of an Outer Message. It illustrates the first 477 Body part (of the Outer Message) as a "multipart/signed" 478 (application/pkcs7-signature) media type: 480 Lines are prepended as follows: 482 o "O: " Outer Message Header Section 484 o "I: " Message Header Section 486 o "W: " Wrapper (MIME Header Section) 487 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 488 O: Message-ID: 489 O: Subject: Meeting at my place 490 O: From: "Alexey Melnikov" 491 O: To: somebody@example.net 492 O: MIME-Version: 1.0 493 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 494 O: protocol="application/pkcs7-signature"; 495 O: boundary=boundary-AM 497 This is a multipart message in MIME format. 498 --boundary-AM 499 W: Content-Type: message/RFC822; forwarded=no 500 W: 501 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 502 I: From: "Alexey Melnikov" 503 I: Message-ID: 504 I: MIME-Version: 1.0 505 I: MMHS-Primary-Precedence: 3 506 I: Subject: Meeting at my place 507 I: To: somebody@example.net 508 I: X-Mailer: Isode Harrier Web Server 509 I: Content-Type: text/plain; charset=us-ascii 511 This is an important message that I don't want to be modified. 513 --boundary-AM 514 Content-Transfer-Encoding: base64 515 Content-Type: application/pkcs7-signature 517 [[base-64 encoded signature]] 519 --boundary-AM-- 521 The Outer Message Header Section is unprotected, while the remainder 522 (Outer Message Body) is protected. The Outer Message Body consists 523 of the wrapper (MIME Header Section) and the Inner Message (Header 524 Section and Body). 526 The wrapper is a simple MIME Header Section with media type "message/ 527 RFC822" containing a Content-Type header field parameter 528 "forwarded=no" followed by an empty line. 530 The Inner Message Header Section is the same as (or a subset of) the 531 Original Message Header Section (cf. Section 4.1.2). 533 The Inner Message Body is the same as the Original Message Body. 535 The Original Message itself may contain any MIME structure. 537 4.1.1.2. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory 538 Hole") 540 An alternative option (based on the former autocrypt "Memory Hole" 541 approach) to be considered, is described in 542 [I-D.autocrypt-lamps-protected-headers]. 544 Unlike the option described in Section 4.1.1.1, this option does not 545 use a "message/RFC822" wrapper to unambiguously delimit the Inner 546 Message. 548 Before choosing this option, the following two issues must be 549 assessed to ensure no interoperability issues result from it: 551 1. How current MIME parser implementations treat non-MIME Header 552 Fields, which are not part of the outermost MIME entity and not 553 part of a message wrapped into a MIME entity of media type 554 "message/rfc822", and how such messages are rendered to the user. 556 [I-D.autocrypt-lamps-protected-headers] provides some examples 557 for testing this. 559 2. MIME-conformance, i.e. whether or not this option is (fully) 560 MIME-conformant [RFC2045] ff., in particular also Section 5.1. of 561 [RFC2046] on "Multipart Media Type). In the following an excerpt 562 of paragraphs that may be relevant in this context: 564 The only header fields that have defined meaning for body parts 565 are those the names of which begin with "Content-". All other 566 header fields may be ignored in body parts. Although they 567 should generally be retained if at all possible, they may be 568 discarded by gateways if necessary. Such other fields are 569 permitted to appear in body parts but must not be depended on. 570 "X-" fields may be created for experimental or private 571 purposes, with the recognition that the information they 572 contain may be lost at some gateways. 574 NOTE: The distinction between an RFC 822 message and a body 575 part is subtle, but important. A gateway between Internet and 576 X.400 mail, for example, must be able to tell the difference 577 between a body part that contains an image and a body part 578 that contains an encapsulated message, the body of which is a 579 JPEG image. In order to represent the latter, the body part 580 must have "Content-Type: message/rfc822", and its body (after 581 the blank line) must be the encapsulated message, with its own 582 "Content-Type: image/jpeg" header field. The use of similar 583 syntax facilitates the conversion of messages to body parts, 584 and vice versa, but the distinction between the two must be 585 understood by implementors. (For the special case in which 586 parts actually are messages, a "digest" subtype is also 587 defined.) 589 The MIME structure of an Email message looks as follows: 591 593 595 597 599 The following example demonstrates how an Original Message might be 600 protected, i.e., the Original Message is contained as Inner Message 601 in the Protected Body of an Outer Message. It illustrates the first 602 Body part (of the Outer Message) as a "multipart/signed" 603 (application/pkcs7-signature) media type: 605 Lines are prepended as follows: 607 o "O: " Outer Message Header Section 609 o "I: " Message Header Section 610 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 611 O: Message-ID: 612 O: Subject: Meeting at my place 613 O: From: "Alexey Melnikov" 614 O: MIME-Version: 1.0 615 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 616 O: protocol="application/pkcs7-signature"; 617 O: boundary=boundary-AM 619 This is a multipart message in MIME format. 620 --boundary-AM 621 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 622 I: From: "Alexey Melnikov" 623 I: Message-ID: 624 I: MIME-Version: 1.0 625 I: MMHS-Primary-Precedence: 3 626 I: Subject: Meeting at my place 627 I: To: somebody@example.net 628 I: X-Mailer: Isode Harrier Web Server 629 I: Content-Type: text/plain; charset=us-ascii 631 This is an important message that I don't want to be modified. 633 --boundary-AM 634 Content-Transfer-Encoding: base64 635 Content-Type: application/pkcs7-signature 637 [[base-64 encoded signature]] 639 --boundary-AM-- 641 The Outer Message Header Section is unprotected, while the remainder 642 (Outer Message Body) is protected. The Outer Message Body consists 643 of the Inner Message (Header Section and Body). 645 The Inner Message Header Section is the same as (or a subset of) the 646 Original Message Header Section (cf. Section 4.1.2). 648 The Inner Message Body is the same as the Original Message Body. 650 The Original Message itself may contain any MIME structure. 652 4.1.2. Inner Message Header Fields 654 It is RECOMMENDED that the Inner Message contains all Header Fields 655 of the Original Message with the exception of the following Header 656 Field, which MUST NOT be included within the Inner Message nor within 657 any other protected part of the message: 659 o Bcc 661 [[ TODO: Bcc handling needs to be further specified (see also 662 Appendix A.1). Certain MUAs cannot properly decrypt messages with 663 Bcc recipients. ]] 665 4.1.3. Wrapper 667 The wrapper is a simple MIME Header Section followed by an empty line 668 preceding the Inner Message (inside the Outer Message Body). The 669 media type of the wrapper MUST be "message/RFC822" and MUST contain 670 the Content-Type header field parameter "forwarded=no" as defined in 671 [I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously 672 delimits the Inner Message from the rest of the message. 674 4.1.4. Outer Message Header Fields 676 To maximize Privacy, it is strongly RECOMMENDED to follow the 677 principle of Data Minimization (cf. Section 2.1). 679 However, the Outer Message Header Section SHOULD contain the 680 Essential Header Fields and, in addition, MUST contain the Header 681 Fields of the MIME Header Section part to describe the encryption or 682 signature as per [RFC8551]. 684 The following Header Fields are defined as the Essential Header 685 Fields: 687 o From 689 o To (if present in the Original Message) 691 o Cc (if present in the Original Message) 693 o Bcc (if present in the Original Message, see also Section 4.1.2 694 and Appendix A.1) 696 o Date 698 o Message-ID 700 o Subject 702 Further processing by the Submission Entity normally depends on part 703 of these Header Fields, e.g. From and Date HFs are required by 705 [RFC5322]. Furthermore, not including certain Header Fields may 706 trigger spam detection to flag the message and/or lead to user 707 experience (UX) issues. 709 For further Data Minimization, the value of the Subject Header Field 710 SHOULD be obfuscated. In addition, the value of other Essential 711 Header Fields MAY be obfuscated. Further Header Fields MAY be 712 obfuscated, though simply not adding those to the Outer Message 713 Header Section SHOULD be preferred over obfuscation. Header Field 714 obfuscation is further specified in Section 4.1.4.1. Header Fields 715 not obfuscated should contain the same values as in the Original 716 Message. 718 The MIME Header Section part is the collection of MIME Header Fields 719 describing the following MIME structure as defined in [RFC2045]. A 720 MIME Header Section part typically includes the following Header 721 Fields: 723 o Content-Type 725 o Content-Transfer-Encoding 727 o Content-Disposition 729 The following example shows the MIME Header Section part of an S/MIME 730 signed message (using application/pkcs7-mime with SignedData): 732 MIME-Version: 1.0 733 Content-Type: application/pkcs7-mime; smime-type=signed-data; 734 name=smime.p7m 735 Content-Transfer-Encoding: base64 736 Content-Disposition: attachment; filename=smime.p7m 738 Depending on the scenario, further Header Fields MAY be exposed in 739 the Outer Message Header Section, which is NOT RECOMMENDED unless 740 justified. Such Header Fields may include e.g.: 742 o References 744 o Reply-To 746 o In-Reply-To 748 4.1.4.1. Obfuscation of Outer Message Header Fields 750 If the values of the following Outer Message Header Fields are 751 obfuscated, those SHOULD assume the following values: 753 * Subject: ... 754 * Message-ID: 755 * Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC) 757 [[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the 758 same week. The Impact of obfuscated Date HF content to certificate 759 validation is for further study, in particular regarding legacy 760 clients. ]] 762 In certain implementations also the From, To, and/or Cc Header Field 763 MAY be obfuscated. Those may be replaced by e.g. 765 o To: Obfuscated 767 Such implementations may need to ensure that the Submission Entity 768 has access to the content of these Header Fields in clear text and is 769 capable of processing those. This is particularly relevant, if 770 proprietary Submission Entities are used. 772 A use case for obfuscation of all Outer Message Header Fields is 773 routing email using onion routing or mix networks (e.g. 774 [pEp.mixnet]). 776 Note: It is for further study to what extent Header Field obfuscation 777 adversely impacts spam filtering. 779 4.1.5. Receiving User Facing Message Header Fields 781 The Receiving User Facing Message SHOULD be a verbatim copy of the 782 Inner Message. 784 4.1.6. Header Field Flow 786 The Following figure depicts the different message representations 787 (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed 788 from: 790 OrigM InnerM Outer(S) OuterM(R) RUFM 792 793 From (OrigM) = From 794 To (OrigM) = To 795 Cc (OrigM) = Cc 796 Bcc (OrigM) = Bcc* 797 Date (OrigM) = Date 798 Message-ID (OrigM)= Message-ID 799 Subject (new) = Subject 800 (new) = 802 PROTECTED: PROTECTED: 803 (new) = 804 From > From > From = From > From 805 To > To > To = To > To 806 Cc* > Cc > Cc = Cc > Cc 807 Bcc* 808 Date > Date > Date = Date > Date 809 Message-ID > Message-ID > Message-ID = Message-ID > Message-ID 810 Subject > Subject > Subject = Subject > Subject 811 > > = > 812 > > = > 813 > > = > 814 * (new)= 816 Legend: 818 o OuterM(S): Outer Message (OuterM) at sending side (before handing 819 it over to the Submission Entity) 821 o OuterM(R): Outer Message at receiving side (as received by the 822 last hop, before decryption and/or signature verification is 823 applied to) 825 o InnerM: Inner Message (that protection is applied to) 827 o RUFM: Receiving User Facing Message 829 o More-HF: Additional Header Fields (HF) in the Original Message 830 (OrigM) 832 o Wrapper: MIME Header Section; with media type (message/RFC822) to 833 unambiguously delimit the inner message from the rest of the 834 message. 836 o MIME-HSp: MIME Header Section part to describe the encryption or 837 signature as per [RFC8551] 839 o Trace-HF: Header Fields added in Transit (between sending and 840 receiving side) as per [RFC5322] 842 o >: taken over / copied from last column 844 o =: propagates unchanged, unless something unusual (e.g. attack) 845 happens 847 o *: HF that is often not present (also further HFs, e.g. To, may 848 not be present). If a HF is not present, naturally it can neither 849 be taken over nor propagated. 851 o (new) / (OrigM): HF or MIME-HSp is generated depending on the 852 decision in Section 4.1.7.1, while '(new)' / '(OrigM)' designate 853 the default. 855 4.1.7. Sending Side Message Processing 857 For a protected message the following steps are applied before a 858 message is handed over to the Submission Entity: 860 4.1.7.1. Step 1: Decide on Protection Level and Information Disclosure 862 The entity applying protection to a message must decide: 864 o Which Protection Level (signature and/or encryption) is applied to 865 the message? This depends on user request and/or local policy as 866 well as availability of cryptographic keys. 868 o Which Header Fields of the Original Message shall be part of the 869 Outer Message Header Section? This typically depends on local 870 policy. By default the Essential Header Fields are part of the 871 Outer Message Header Section; cf. Section 4.1.4. 873 o Which of these Header Fields are to be obfuscated? This depends 874 on local policy and/or specific Privacy requirements of the user. 875 By default only the Subject Header Field is obfuscated; cf. 876 Section 4.1.4.1. 878 4.1.7.2. Step 2: Compose the Outer Message Header Section 880 Depending on the decision in Section 4.1.7.1, compose the Outer 881 Message Header Section. (Note that this also includes the necessary 882 MIME Header Section part for the following protection layer.) 883 Outer Header Fields that are not obfuscated should contain the same 884 values as in the Original Message (except for MIME Header 885 Section part, which depends on the Protection Level selected in 886 Section 4.1.7.1). 888 4.1.7.3. Step 3: Apply Protection to the Original Message 890 Depending on the Protection Level selected in Section 4.1.7.1, apply 891 signature and/or encryption to the Original Message, including the 892 wrapper (as per [RFC8551]), and set the result to the message as 893 Outer Message Body. 895 The resulting (Outer) Message is then typically handed over to the 896 Submission Entity. 898 [[ TODO: Example ]] 900 4.1.8. Receiving Side Message Processing 902 When a protected message is received, the following steps are 903 applied: 905 4.1.8.1. Step 1: Decrypt message and/or check signature 907 Depending on the Protection Level, the received message is decrypted 908 and/or its signature is checked as per [RFC8551]. 910 4.1.8.2. Step 2: Construct the Receiving User Facing Message 912 The Receiving User Facing Message is constructed according to 913 Section 4.1.5. 915 The resulting message is handed over for further processing, which 916 typically involves rendering it for the user. 918 Note: Further study is needed to determine whether or not the Outer 919 Message Header Section, as received from the last hop, is preserved 920 for the user, and if so, how this is to be achieved. 922 4.2. Backward Compatibility Use Cases 924 4.2.1. Receiving Side MIME-Conformant 926 This section applies to the case where the sending side (fully) 927 supports Header Protection as specified in this document, while the 928 receiving side does not support this specification, but is MIME- 929 conformant according to [RFC2045], ff. (cf. Section 3.1.2) and 930 Section 3.1.2.1) 931 The sending side specification of the main use case (cf. 932 Section 4.1) MUST ensure that receiving sides can still recognize and 933 display or offer to display the encapsulated data in accordance with 934 its media type (cf. [RFC2049], Section 2). In particular, receiving 935 sides that do not support this specification, but are MIME-conformant 936 according to [RFC2045], ff. can still recognize and display the 937 Message intended for the user. 939 [[ TODO: Verify once solution is stable and update last sentence. ]] 941 4.2.2. Receiving Side Not MIME-Conformant 943 This section applies to the case where the sending side (fully) 944 supports Header Protection as specified in this document, while the 945 receiving side neither supports this specification *nor* is MIME- 946 conformant according to [RFC2045], ff. (cf. Section 3.1.2 and 947 Section 3.1.2.2). 949 [I-D.autocrypt-lamps-protected-headers] describes a possible way to 950 achieve backward compatibility with existing S/MIME (and PGP/MIME) 951 implementations that predate this specification and are not MIME- 952 conformant (Legacy Display) either. It mainly focuses on email 953 clients that do not render emails using header protection (in a user 954 friendly manner) and may confuse the user. While this has been 955 observed occasionally in PGP/MIME (cf. [RFC3156]), the extent of 956 this problem with S/MIME implementations is still unclear. (Note: At 957 this time, none of the samples in 958 [I-D.autocrypt-lamps-protected-headers] apply header protection as 959 specified in Section 3.1 of [RFC8551], which is wrapping as Media 960 Type "message/RFC822".) 962 Should serious backward compatibility issues with rendering at the 963 receiver be discovered, the Legacy Display format described in 964 [I-D.autocrypt-lamps-protected-headers] may serve as a basis to 965 mitigate those issues (cf. Section 4.2). 967 Another variant of backward compatibility has been implemented by pEp 968 [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has 969 implemented this for PGP/MIME, but not yet S/MIME. 971 5. Security Considerations 973 [[ TODO ]] 975 6. Privacy Considerations 977 [[ TODO ]] 979 7. IANA Considerations 981 This document requests no action from IANA. 983 [[ RFC Editor: This section may be removed before publication. ]] 985 8. Acknowledgments 987 The authors would like to thank the following people who have 988 provided helpful comments and suggestions for this document: Berna 989 Alp, Claudio Luck, Daniel Kahn Gillmor, David Wilson, Hernani 990 Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert 991 Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. 993 9. References 995 9.1. Normative References 997 [I-D.ietf-lamps-header-protection-requirements] 998 Melnikov, A. and B. Hoeneisen, "Problem Statement and 999 Requirements for Header Protection", draft-ietf-lamps- 1000 header-protection-requirements-01 (work in progress), 1001 October 2019. 1003 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1004 Extensions (MIME) Part One: Format of Internet Message 1005 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1006 . 1008 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1009 Extensions (MIME) Part Two: Media Types", RFC 2046, 1010 DOI 10.17487/RFC2046, November 1996, 1011 . 1013 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1014 Extensions (MIME) Part Five: Conformance Criteria and 1015 Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, 1016 . 1018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Levels", BCP 14, RFC 2119, 1020 DOI 10.17487/RFC2119, March 1997, 1021 . 1023 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1024 DOI 10.17487/RFC5322, October 2008, 1025 . 1027 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1028 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1029 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1030 April 2019, . 1032 9.2. Informative References 1034 [I-D.autocrypt-lamps-protected-headers] 1035 Einarsson, B., juga, j., and D. Gillmor, "Protected 1036 Headers for Cryptographic E-mail", draft-autocrypt-lamps- 1037 protected-headers-02 (work in progress), December 2019. 1039 [I-D.melnikov-iana-reg-forwarded] 1040 Melnikov, A. and B. Hoeneisen, "IANA Registration of 1041 Content-Type Header Field Parameter 'forwarded'", draft- 1042 melnikov-iana-reg-forwarded-00 (work in progress), 1043 November 2019. 1045 [I-D.pep-email] 1046 Marques, H., "pretty Easy privacy (pEp): Email Formats and 1047 Protocols", draft-pep-email-00 (work in progress), July 1048 2020. 1050 [pEp.mixnet] 1051 pEp Foundation, "Mixnet", June 2020, 1052 . 1054 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1055 "MIME Security with OpenPGP", RFC 3156, 1056 DOI 10.17487/RFC3156, August 2001, 1057 . 1059 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1060 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1061 . 1063 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1064 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1065 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1066 . 1068 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1069 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 1070 . 1072 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1073 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1074 DOI 10.17487/RFC7208, April 2014, 1075 . 1077 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1078 Message Authentication, Reporting, and Conformance 1079 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1080 . 1082 Appendix A. Additional information 1084 A.1. Stored Variants of Messages with Bcc 1086 Messages containing at least one recipient address in the Bcc header 1087 field may appear in up to three different variants: 1089 1. The message for the recipient addresses listed in To or Cc header 1090 fields, which must not include the Bcc header field neither for 1091 signature calculation nor for encryption. 1093 2. The message(s) sent to the recipient addresses in the Bcc header 1094 field, which depends on the implementation: 1096 a) One message for each recipient in the Bcc header field 1097 separately, with a Bcc header field containing only the address 1098 of the recipient it is sent to. 1100 b) The same message for each recipient in the Bcc header field 1101 with a Bcc header field containing an indication such as 1102 "Undisclosed recipients", but no addresses. 1104 c) The same message for each recipient in the Bcc header field 1105 which does not include a Bcc header field (this message is 1106 identical to 1. / cf. above). 1108 3. The message stored in the 'Sent'-Folder of the sender, which 1109 usually contains the Bcc unchanged from the original message, 1110 i.e., with all recipient addresses. 1112 The most privacy preserving method of the alternatives (2a, 2b, and 1113 2c) is to standardize 2a, as in the other cases (2b and 2c), 1114 information about hidden recipients is revealed via keys. In any 1115 case, the message has to be cloned and adjusted depending on the 1116 recipient. 1118 Appendix B. Document Changelog 1120 [[ RFC Editor: This section is to be removed before publication ]] 1122 o draft-ietf-lamps-header-protection-00 1124 * Initial version (text partially taken over from 1125 [I-D.ietf-lamps-header-protection-requirements] 1127 Appendix C. Open Issues 1129 [[ RFC Editor: This section should be empty and is to be removed 1130 before publication. ]] 1132 o Ensure "protected header" (Ex-Memory-Hole) option is (fully) 1133 compliant with the MIME standard, in particular also [RFC2046], 1134 Section 5.1. (Multipart Media Type) Section 4.1.1.2. 1136 o Decide on format of obfuscated HFs, in particular Date HF 1137 (Section 4.1.4.1) 1139 o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1) 1141 o More examples (e.g. in Section 4.1.7) 1143 o Should Outer Message Header Section (as received) be preserved for 1144 the user? (Section 4.1.8.2) 1146 o Decide on whether or not merge requirements from 1147 [I-D.ietf-lamps-header-protection-requirements] into this 1148 document. 1150 o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to 1151 merge into this document. 1153 o Enhance Introduction Section 1 and Problem Statement (Section 2). 1155 o Decide on whether or not specification for more legacy HP 1156 requirements should be added to this document (Section 3.1.2). 1158 o Verify simple backward compatibility case (Receiving Side MIME- 1159 Conformant) is working; once solution is stable and update 1160 paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1 1161 accordingly. 1163 o Verify ability to distinguish between Messages with Header 1164 Protection as specified in this document and legacy clients and 1165 update Section 3.1 accordingly. 1167 o Improve definitions of Protection Levels and enhance list of 1168 Protection Levels (Section 3.2, Section 4). 1170 o Privacy Considerations Section 6 1172 o Security Considerations Section 5 1174 Authors' Addresses 1176 Bernie Hoeneisen 1177 pEp Foundation 1178 Oberer Graben 4 1179 CH-8400 Winterthur 1180 Switzerland 1182 Email: bernie.hoeneisen@pep.foundation 1183 URI: https://pep.foundation/ 1185 Alexey Melnikov 1186 Isode Ltd 1187 14 Castle Mews 1188 Hampton, Middlesex TW12 2NP 1189 UK 1191 Email: alexey.melnikov@isode.com