idnits 2.17.1 draft-ietf-lamps-header-protection-requirements-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 date (July 08, 2019) is 1744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational B. Hoeneisen 5 Expires: January 9, 2020 Ucom.ch 6 July 08, 2019 8 Problem Statement and Requirements for Header Protection 9 draft-ietf-lamps-header-protection-requirements-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 issue has been expressed in the IETF LAMPS Working Group only 16 recently. The existing S/MIME specification is likely to be updated 17 regarding header protection. 19 Several LAMPS WG participants expressed the opinion that whatever 20 mechanism will be chosen, it should not be limited to S/MIME, but 21 also applicable to PGP/MIME. 23 This document describes the problem statement, generic use cases, and 24 requirements. Additionally it drafts possible solutions to address 25 the challenge. Finally some best practices are collected. 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 January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 68 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. General Requirements . . . . . . . . . . . . . . . . . . 6 70 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 7 72 4.2. Additional Requirements for Backward-Compatibility With 73 Legacy Clients Unaware of Header Protection . . . . . . . 8 74 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 75 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8 76 4.3. Additional Requirements for Backward-Compatibility with 77 Legacy Header Protection Systems (if supported) . . . . . 8 78 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9 79 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9 80 5. Options to Achieve Header Protection . . . . . . . . . . . . 9 81 5.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . . . 9 82 5.2. Option 2: Wrapping with message/rfc822 or message/global 9 83 5.2.1. Content-Type Parameter "forwarded" . . . . . . . . . 10 84 5.3. Option 2.1: Progressive Header Disclosure . . . . . . . . 10 85 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5.4.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . 12 87 5.4.2. Option 2: Wrapping with message/rfc822 or 88 message/global . . . . . . . . . . . . . . . . . . . 13 89 5.4.3. Option 2.1 Progressive Header Disclosure . . . . . . 14 90 6. Sending Side Considerations . . . . . . . . . . . . . . . . . 14 91 6.1. Candidate Header Fields for Header Protection . . . . . . 14 92 7. Receiving Side Considerations . . . . . . . . . . . . . . . . 16 93 7.1. Which Header Fields to Display to User . . . . . . . . . 16 94 7.2. Mail User Agent Algorithm for deciding which version of a 95 header field to display . . . . . . . . . . . . . . . . . 16 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 102 12.2. Informative References . . . . . . . . . . . . . . . . . 18 103 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 18 104 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 107 1. Introduction 109 [[ Note: Please be advised that this document is early work-in- 110 progress, and will substantially change in future revisions. ]] 112 A range of protocols for the protection of electronic mail (email) 113 exist, which allow to assess the authenticity and integrity of the 114 email headers section or selected header fields from the domain-level 115 perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376] 116 and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message 117 Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These 118 protocols, while essential to responding to a range of attacks on 119 email, do not offer full end-to-end protection to the headers section 120 and are not capable of providing privacy for the information 121 contained therein. 123 The need for means of Data Minimization, which includes data 124 spareness and the hiding of all technically concealable information 125 whenever possible, has grown in importance over the past years. 127 A standard for end-to-end protection of the email headers section 128 exists for S/MIME since version 3.1. (cf. [RFC8551]): 130 In order to protect outer, non-content-related message header 131 fields (for instance, the "Subject", "To", "From", and "Cc" 132 fields), the sending client MAY wrap a full MIME message in a 133 message/rfc822 wrapper in order to apply S/MIME security services 134 to these header fields. 136 No mechanism for header protection has been standardized for PGP 137 (Pretty Good Privacy) yet. 139 End-to-end protection for the email headers section is currently not 140 widely implemented - neither for messages protected by means of 141 S/MIME nor PGP. At least two variants of header protection are known 142 to be implemented. 144 This document describes the problem statement, generic use cases 145 (Section 3) and requirements for header protection (Section 4). 146 Additionally it drafts possible solutions to address the challenge. 147 However, the final solution will be determined by the IETF LAMPS WG. 148 Finally, some best practices are collected. 150 [[ TODO: enhance this section ]] 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 1.2. Terms 160 The following terms are defined for the scope of this document: 162 o Header Field:: cf. [RFC5322] 164 o Header Section: cf. [RFC5322] 166 o Signed-only message: a multipart/signed or application/pkcs7-mime 167 containing SignedData message which doesn't contain any encrypted 168 layer. I.e. this is a message which is not encrypted and not 169 encrypted + signed. 171 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 172 form of active wiretapping attack in which the attacker intercepts 173 and selectively modifies communicated data to masquerade as one or 174 more of the entities involved in a communication association." 176 2. Problem Statement 178 The LAMPS charter contains the following Work Item: 180 Update the specification for the cryptographic protection of email 181 headers - both for signatures and encryption - to improve the 182 implementation situation with respect to privacy, security, 183 usability and interoperability in cryptographically-protected 184 electronic mail. Most current implementations of 185 cryptographically-protected electronic mail protect only the body 186 of the message, which leaves significant room for attacks against 187 otherwise-protected messages. 189 [[ TODO: enhance this section ]] 191 3. Use Cases 193 In the following, we show the generic use cases that need to be 194 addressed independently of whether S/MIME, PGP/MIME or any other 195 technology is used for which Header Protection (HP) is to be applied 196 to. 198 3.1. Interactions 200 The main interaction case for Header Protection (HP) is: 202 1) Both peers (sending and receiving side) fully support HP 204 For backward compatibility of legacy clients - unaware of any HP - 205 the following intermediate interactions need to be considered as 206 well: 208 2) The sending side fully supports HP, while the receiving side does 209 not support any HP 211 3) The sending side does not support any HP, while the receiving 212 side fully supports HP (trivial case) 214 4) Neither the sending side nor the receiving side supports any HP 215 (trivial case) 217 The following intermediate use cases may need to be considered as 218 well for backward compatibility with legacy HP systems, such as 219 S/MIME since version 3.1 (cf. [RFC8551]), in the following 220 designated as legacy HP: 222 5) The sending side fully supports HP, while the receiving side 223 supports legacy HP only 225 6) The sending side supports legacy HP only, while the receiving side 226 fully supports HP 228 7) Both peers (sending and receiving side) support legacy HP only 230 8) The sending side supports legacy HP only, while the receiving side 231 does not support any HP 233 9) The sending side does not support any HP, while the receiving side 234 supports legacy HP only (trivial case) 236 Note: It is to be decided whether to ensure legacy HP systems do not 237 conflict with any new solution for HP at all or whether (and to which 238 degree) backward compatibility to legacy HP systems shall be 239 maintained. 241 [[ TODO: Decide in which form legacy HP requirements should remain in 242 this document. ]] 244 3.2. Protection Levels 246 The following protection levels need to be considered: 248 a) signature and encryption 250 b) signature only 252 c) encryption only [[ TODO: verify whether relevant ]] 254 4. Requirements 256 In the following a list of requirements that need to be addressed 257 independently of whether S/MIME, PGP/MIME or any other technology is 258 used to apply HP to. 260 4.1. General Requirements 262 This subsection is listing the requirements to address use case 1) 263 (cf. Section 3.1). 265 G1: Define the format for HP for all protection levels MIME 266 structure, Content-Type (including all parameters, such as 267 "charset" and "name"), Content-Disposition (including all 268 parameters, such as "filename"), and Content-Transfer-Encoding. 270 G2: To foster wide implementation of the new solution, it shall be 271 easily implementable. Unless needed for maximizing protection and 272 privacy, existing implementations shall not require substantial 273 changes in the existing code base. In particular also MIME 274 libraries widely used shall not need to be changed to comply with 275 the new mechanism for HP. 277 G3: There SHOULD be only one format that covers all Protection Levels 278 (cf. {{protection-levels}})) 280 [[ TODO: Should this one remain in the document? 281 If yes, consider improve / rewrite sentence 282 ]] 284 G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in 285 particular downgrade attacks, are mitigated as good as possible. 287 4.1.1. Sending Side 289 GS1: Determine which Header Fields (HFs) should or must be protected 290 at least for signed only email. 292 GS2: Determine which HFs should or must be sent in clear of an 293 encrypted email. 295 GS3: Determine which HF should not or must not be included in the 296 visible header (for transport) of an encrypted email, with the 297 default being that whatever is not needed from GS2 is not put 298 into the unencrypted transport headers, thus fulfilling data 299 minimization requirements (including data spareness and hiding 300 of all information that technically can be hidden). 302 GS4: Determine which HF to not to include to any HP part (e.g. Bcc). 304 4.1.2. Receiving Side 305 GR1: Determine how HF should be displayed to the user in case of 306 conflicting information between the protected and unprotected 307 headers. 309 GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in 310 particular downgrade attacks, can be detected. 312 4.2. Additional Requirements for Backward-Compatibility With Legacy 313 Clients Unaware of Header Protection 315 This sub-section addresses the use cases 2) - 4) (cf. Section 3.1) 317 B1: Depending on the solution, define a means to distinguish between 318 forwarded messages and encapsulated messages using new HP 319 mechanism. 321 4.2.1. Sending side 323 BS1: Define how full HP support can be indicated to outgoing 324 messages. 326 BS2: Define how full HP support of the receiver can be detected or 327 guessed. 329 BS3: Ensure a HP unaware receiving side easily can display the 330 "Subject" HF to the user. 332 4.2.2. Receiving side 334 BR1: Define how full HP support can be detected in incoming messages. 336 4.3. Additional Requirements for Backward-Compatibility with Legacy 337 Header Protection Systems (if supported) 339 This sub-section addresses the use cases 5) - 9) (cf. Section 3.1). 341 LS1: Depending on the solution, define a means to distinguish between 342 forwarded messages, legacy encapsulated messages, and 343 encapsulated messages using new HP mechanism. 345 LS2: The solution should be backward compatible to existing solutions 346 and aim to minimize the implementation effort to include support 347 for existing solutions. 349 4.3.1. Sending Side 351 LSS1: Determine how legacy HP support can be indicated to outgoing 352 messages. 354 LSS2: Determine how legacy HP support of the receiver can be detected 355 or guessed. 357 4.3.2. Receiving Side 359 LSR1: Determine how legacy HP support can be detected in incoming 360 messages. 362 5. Options to Achieve Header Protection 364 In the following a set of Options to achieve Email Header Protection. 365 It is expected that the IETF LAMPS WG chooses an option to update 366 [RFC8551] wrt. Header Protection. 368 5.1. Option 1: Memory Hole 370 Memory Hole approach works by copying the normal message header 371 fields into the MIME header section of the top level protected body 372 part. Since the MIME body part header section is itself covered by 373 the protection mechanisms (signing and/or encryption) it shares the 374 protections of the message body. 376 [[ TODO: add more information on memory hole ]] 378 5.2. Option 2: Wrapping with message/rfc822 or message/global 380 Wrapping with message/rfc822 (or message/global) works by copying the 381 normal message header fields into the MIME header section of the top 382 level protect body part 384 [[ TODO: consider rephrasing, as not only the header fields is 385 copied, but also the content.]] 387 and then prepending them with "Content-Type: message/rfc822; 388 forwarded=no\r\n" or "Content-Type: message/global; 389 forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF. 390 Since the MIME body part header section is itself covered by the 391 protection mechanisms (signing and/or encryption) it shares the 392 protections of the message body. 394 5.2.1. Content-Type Parameter "forwarded" 396 This section outlines how the new "forwarded" Content-Type header 397 field parameter could be defined (probably in a separate document) 398 and how header section wrapping works: 400 This document defines a new Content-Type header field parameter 401 [RFC2045] with name "forwarded". The parameter value is case- 402 insensitive and can be either "yes" or "no". (The default value 403 being "yes"). The parameter is only meaningful with media type 404 "message/rfc822" and "message/global" [RFC6532] when used within 405 S/MIME signed or encrypted body parts. The value "yes" means that 406 the message nested inside "message/rfc822" ("message/global") is a 407 forwarded message and not a construct created solely to protect the 408 inner header section. 410 Instructions in [RFC8551] describing how to protect the Email message 411 header section [RFC5322], by wrapping the message inside a message/ 412 rfc822 container [RFC2045] are thus updated to read: 414 In order to protect outer, non-content-related message header 415 fields (for instance, the "Subject", "To", "From", and "Cc" 416 fields), the sending client MAY wrap a full MIME message in a 417 message/rfc822 wrapper in order to apply S/MIME security services 418 to these header fields. It is up to the receiving client to 419 decide how to present this "inner" header section along with the 420 unprotected "outer" header section. 422 When an S/MIME message is received, if the top-level protected 423 MIME entity has a Content-Type of message/rfc822 or message/global 424 without the "forwarded" parameter or with the "forwarded" 425 parameter set to "no", it can be assumed that the intent was to 426 provide header protection. This entity SHOULD be presented as the 427 top-level message, taking into account header section merging 428 issues as previously discussed. 430 5.3. Option 2.1: Progressive Header Disclosure 432 This option is similar to Option 2 (cf. Section 5.2). It also makes 433 use the Content-Type parameter "forwarded" (cf. Section 5.2.1). 435 pEp for email [I-D.marques-pep-email] defines a fixed MIME structure 436 for its innermost message structure. Security comes just next after 437 privacy in pEp, for which reason the application of signatures 438 without encryption to messages in transit is not considered 439 purposeful. pEp for email, either expects to transfer messages in 440 cleartext without signature or encryption, or transfer them encrypted 441 and with enclosed signature and necessary public keys so that replies 442 can be immediately upgraded to encrypted messages. 444 The pEp message format is equivalent to the S/MIME standard in 445 ensuring header protection, in that the whole message is protected 446 instead, by wrapping it and providing cryptographic services to the 447 whole original message. However, for the purpose of allowing the 448 insertion of public keys, the root entity of the protected message is 449 thus nested once more into an additional multipart/mixed MIME entity. 450 The current pEp proposal is for PGP/MIME, while an extension to 451 S/MIME is also on the roadmap. 453 pEp has also implemented the above (in Section 5.2.1) described 454 Content-Type parameter "forwarded" to distinguish between 455 encapsulated and forwarded emails. 457 More information on progressive header disclosure can be found in 458 [I-D.luck-lamps-pep-header-protection]. 460 5.4. Examples 462 Examples in subsequent sections assume that an email client is trying 463 to protect (sign) the following initial message: 465 Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 466 From: "Alexey Melnikov" 467 Message-ID: 468 MIME-Version: 1.0 469 MMHS-Primary-Precedence: 3 470 Subject: Meeting at my place 471 To: somebody@example.net 472 X-Mailer: Isode Harrier Web Server 473 Content-Type: text/plain; charset=us-ascii 475 This is an important message that I don't want to be modified. 477 Without message header protection the corresponding signed message 478 might look like this. (Lines prepended by "O: " are the outer 479 header.) 481 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 482 O: Message-ID: 483 O: Subject: Meeting at my place 484 O: From: "Alexey Melnikov" 485 O: MIME-Version: 1.0 486 O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; 487 O: protocol="application/pkcs7-signature"; 488 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 490 This is a multipart message in MIME format. 491 --.cbe16d2a-e1a3-4220-b821-38348fc97237 492 Content-Type: text/plain; charset=us-ascii 494 This is an important message that I don't want to be modified. 496 --.cbe16d2a-e1a3-4220-b821-38348fc97237 497 Content-Transfer-Encoding: base64 498 content-type: application/pkcs7-signature 500 [[base-64 encoded signature]] 502 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 504 5.4.1. Option 1: Memory Hole 506 The following example demonstrates how header section and payload of 507 a protect body part might look like. For example, this will be the 508 first body part of a multipart/signed message or the signed and/or 509 encrypted payload of the application/pkcs7-mime body part. Lines 510 prepended by "O: " are the outer header section. Lines prepended by 511 "I: " are the inner header section. 513 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 514 O: Message-ID: 515 O: Subject: Meeting at my place 516 O: From: "Alexey Melnikov" 517 O: MIME-Version: 1.0 518 O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; 519 O: protocol="application/pkcs7-signature"; 520 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 522 This is a multipart message in MIME format. 523 --.cbe16d2a-e1a3-4220-b821-38348fc97237 524 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 525 I: From: "Alexey Melnikov" 526 I: Message-ID: 527 I: MIME-Version: 1.0 528 I: MMHS-Primary-Precedence: 3 529 I: Subject: Meeting at my place 530 I: To: somebody@example.net 531 I: X-Mailer: Isode Harrier Web Server 532 I: Content-Type: text/plain; charset=us-ascii 534 This is an important message that I don't want to be modified. 536 --.cbe16d2a-e1a3-4220-b821-38348fc97237 537 Content-Transfer-Encoding: base64 538 content-type: application/pkcs7-signature 540 [[base-64 encoded signature]] 542 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 544 5.4.2. Option 2: Wrapping with message/rfc822 or message/global 546 The following example demonstrates how header section and payload of 547 a protect body part might look like. For example, this will be the 548 first body part of a multipart/signed message or the signed and/or 549 encrypted payload of the application/pkcs7-mime body part. Lines 550 prepended by "O: " are the outer header section. Lines prepended by 551 "I: " are the inner header section. Lines prepended by "W: " are the 552 wrapper. 554 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 555 O: Message-ID: 556 O: Subject: Meeting at my place 557 O: From: "Alexey Melnikov" 558 O: MIME-Version: 1.0 559 O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; 560 O: protocol="application/pkcs7-signature"; 561 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 563 This is a multipart message in MIME format. 564 --.cbe16d2a-e1a3-4220-b821-38348fc97237 565 W: Content-Type: message/rfc822; forwarded=no 566 W: 567 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 568 I: From: "Alexey Melnikov" 569 I: Message-ID: 570 I: MIME-Version: 1.0 571 I: MMHS-Primary-Precedence: 3 572 I: Subject: Meeting at my place 573 I: To: somebody@example.net 574 I: X-Mailer: Isode Harrier Web Server 575 I: Content-Type: text/plain; charset=us-ascii 577 This is an important message that I don't want to be modified. 579 --.cbe16d2a-e1a3-4220-b821-38348fc97237 580 Content-Transfer-Encoding: base64 581 content-type: application/pkcs7-signature 583 [[base-64 encoded signature]] 585 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 587 5.4.3. Option 2.1 Progressive Header Disclosure 589 This looks similar as in option 2. Specific examples can be found in 590 [I-D.luck-lamps-pep-header-protection]. 592 [[ TODO: include an example of the same style. ]] 594 6. Sending Side Considerations 596 6.1. Candidate Header Fields for Header Protection 598 [[ TODO: This section is very early stage and needs more work. ]] 599 For a signed-only message, it is RECOMMENDED that all "outer" header 600 fields are identical to the "inner" protected header fields. This 601 would mean that all header fields are signed. In this case, the 602 "outer" header fields simply match the protected header fields. And 603 in the case that the "outer" header fields differ, they can simply be 604 replaced with their protected versions when displayed to the user. 606 [[ TODO: Decide whether "Bcc" header field should be excluded. Also 607 verify whether this requirement applies generally or just for 608 specific implementations. ]] 610 When generating encrypted or encrypted+signed S/MIME messages which 611 protect header fields: 613 1. If a header field is being encrypted because it is sensitive, its 614 true value MUST NOT be included in the outer header. If the 615 header field is mandatory according to [RFC5322], a stub value 616 (or a value indicating that the outer value is not to be used) is 617 to be included in the outer header section. 619 2. The outer header section SHOULD be minimal in order to avoid 620 disclosure of confidential information. It is recommended that 621 the outer header section only contains "Date" (set to the same 622 value as in the inner header field, or, if the Date value is also 623 sensitive, to Monday 9am of the same week), possibly "Subject" 624 and "To"/"Bcc" header fields. ("From", "Date", and at least one 625 destination header field is mandatory as per [RFC5322].) In 626 particular, Keywords, In-Reply-To and References header fields 627 SHOULD NOT be included in the outer header; "To" and "Cc" header 628 fields should be omitted and replaced with "Bcc: undisclosed- 629 recipients;". 631 But note that having key header fields duplicated in the outer 632 header is convenient for many message stores (e.g. IMAP) and 633 clients that can't decode S/MIME encrypted messages. In 634 particular, Subject/To/Cc/Bcc/Date header field values are 635 returned in IMAP ENVELOPE FETCH data item [RFC3501], which is 636 frequently used by IMAP clients in order to avoid parsing message 637 header. 639 3. The "Subject" header field value of the outer header section 640 SHOULD either be identical to the inner "Subject" header field 641 value, or contain a clear indication that the outer value is not 642 to be used for display (the inner header field value would 643 contain the true value). 645 Note that recommendations listed above typically only apply to non 646 MIME header fields (header fields with names not starting with 647 "Content-" prefix), but there are exception, e.g. Content-Language. 649 Note that the above recommendations can also negatively affect anti- 650 spam processing. 652 7. Receiving Side Considerations 654 7.1. Which Header Fields to Display to User 656 When displaying S/MIME messages which protect header fields (whether 657 they are signed-only, encrypted or encrypted+signed): 659 1. The outer header fields might be tampered with, so a receiving 660 client SHOULD ignore them, unless they are protected in some 661 other way(_). If a header field is present in the inner header, 662 only the inner header field value MUST be displayed (and the 663 corresponding outer value must be ignored). If a particular 664 header field is only present in the outer header, it MAY be 665 ignored (not displayed) or it MAY be displayed with a clear 666 indicator that it is not trustworthy(_). 668 (*) - this only applies if the header field is not protected is 669 some other way, for example with a DKIM signature that validates 670 and is trusted. 672 7.2. Mail User Agent Algorithm for deciding which version of a header 673 field to display 675 [[ TODO: describe how to recurse to find the innermost protected root 676 body part, extract header fields from it and propagate them to the 677 top level. This should also work for triple-wrapped messages.]] 679 8. Security Considerations 681 This document talks about UI considerations, including security 682 considerations, when processing messages protecting header fields. 683 One of the goals of this document is to specify UI for displaying 684 such messages which is less confusing/misleading and thus more 685 secure. 687 The document is not defining new protocol, so it doesn't create any 688 new security concerns not already covered by S/MIME [RFC8551], MIME 689 [RFC2045] and Email [RFC5322] in general. 691 9. Privacy Considerations 693 [[ TODO ]] 695 10. IANA Considerations 697 This document requests no action from IANA. 699 [[ RFC Editor: This section may be removed before publication. ]] 701 11. Acknowledgments 703 The authors would like to thank the following people who have 704 provided helpful comments and suggestions for this document: David 705 Wilson, Steve Kille, Wei Chuang, and Robert Williams 707 Essential parts of [I-D.luck-lamps-pep-header-protection] have been 708 merged into this document. Special thanks to its author Claudio 709 Luck. For further Acknowledgments, please refer to Acknowledgments 710 section of [I-D.luck-lamps-pep-header-protection]. 712 David Wilson came up with the idea of defining a new Content-Type 713 header field parameter to distinguish forwarded messages from inner 714 header field protection constructs. 716 12. References 718 12.1. Normative References 720 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 721 Extensions (MIME) Part One: Format of Internet Message 722 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 723 . 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 731 DOI 10.17487/RFC5322, October 2008, 732 . 734 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 735 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 736 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 737 April 2019, . 739 12.2. Informative References 741 [I-D.luck-lamps-pep-header-protection] 742 Luck, C., "pretty Easy privacy (pEp): Progressive Header 743 Disclosure", draft-luck-lamps-pep-header-protection-03 744 (work in progress), July 2019. 746 [I-D.marques-pep-email] 747 Marques, H., "pretty Easy privacy (pEp): Email Formats and 748 Protocols", draft-marques-pep-email-02 (work in progress), 749 October 2018. 751 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 752 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 753 . 755 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 756 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 757 . 759 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 760 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 761 RFC 6376, DOI 10.17487/RFC6376, September 2011, 762 . 764 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 765 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 766 2012, . 768 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 769 Authorizing Use of Domains in Email, Version 1", RFC 7208, 770 DOI 10.17487/RFC7208, April 2014, 771 . 773 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 774 Message Authentication, Reporting, and Conformance 775 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 776 . 778 Appendix A. Document Changelog 780 [[ RFC Editor: This section is to be removed before publication ]] 782 o draft-ietf-lamps-header-protection-requirements-00 784 * Initial version 786 Appendix B. Open Issues 788 [[ RFC Editor: This section should be empty and is to be removed 789 before publication. ]] 791 o Enhance Introduction and Problem Statement sections 793 o Decide in which form legacy HP requirements should remain in this 794 document 796 o Signed-only protection needs further study 798 * pEp only does header protection by applying both signing and 799 encryption. Technically it is also possible to sign, but not 800 encrypt the protected messages. This needs further study. 801 Feedback from IETF-104: Probably no need to specify it, but 802 need to document the case. 804 o Should requirement G3 remain? If you consider improve / rewrite 805 it. 807 o Add more text on Memory Hole 809 o Rephrase Section 5.2 811 o Add example to Section 5.4.3 813 o Resolve question regarding Bcc in Section 6.1 815 o Rewrite Section 6.1 817 o Write Section 7.2 819 o Correct terminology for Header(s) and Header Fields throughout the 820 document (editorial). 822 * Header: Whole Header Section of the message 824 * Header Field: Part / single Line inside a Header (Section) 826 Authors' Addresses 827 Alexey Melnikov 828 Isode Ltd 829 14 Castle Mews 830 Hampton, Middlesex TW12 2NP 831 UK 833 Email: alexey.melnikov@isode.com 835 Bernie Hoeneisen 836 Ucom Standards Track Solutions GmbH 837 CH-8046 Zuerich 838 Switzerland 840 Phone: +41 44 500 52 40 841 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 842 URI: https://ucom.ch/