idnits 2.17.00 (12 Aug 2021) /tmp/idnits12370/draft-ietf-lamps-header-protection-requirements-01.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 (October 28, 2019) is 929 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 (~~), 2 warnings (==), 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: April 30, 2020 Ucom.ch 6 October 28, 2019 8 Problem Statement and Requirements for Header Protection 9 draft-ietf-lamps-header-protection-requirements-01 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 likely to be updated 17 regarding header protection. 19 This document describes the problem statement, generic use cases, and 20 requirements of 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 April 30, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 5 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 70 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8 71 4.2. Additional Requirements for Backward-Compatibility With 72 Legacy Clients Unaware of Header Protection . . . . . . . 8 73 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 74 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 9 75 4.3. Additional Requirements for Backward-Compatibility with 76 Legacy Header Protection Systems (if supported) . . . . . 9 77 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9 78 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 9.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. Implementation Considerations . . . . . . . . . . . 12 87 A.1. Options to Achieve Header Protection . . . . . . . . . . 12 88 A.1.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . 12 89 A.1.2. Option 2: Wrapping with message/rfc822 or 90 message/global . . . . . . . . . . . . . . . . . . . 12 91 A.1.3. Option 2.1: Progressive Header Disclosure . . . . . . 13 92 A.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 14 93 A.2. Sending Side Considerations . . . . . . . . . . . . . . . 20 94 A.2.1. Candidate Header Fields for Header Protection . . . . 20 95 A.3. Receiving Side Considerations . . . . . . . . . . . . . . 21 96 A.3.1. Which Header Fields to Display to User . . . . . . . 22 97 A.3.2. Mail User Agent Algorithm for deciding which version 98 of a header field to display . . . . . . . . . . . . 22 99 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 22 100 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 A range of protocols for the protection of electronic mail (email) 106 exist, which allow to assess the authenticity and integrity of the 107 email headers section or selected header fields (HF) from the domain- 108 level perspective, specifically DomainKeys Identified Mail (DKIM) 109 [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain- 110 based Message Authentication, Reporting, and Conformance (DMARC) 111 [RFC7489]. These protocols, while essential to responding to a range 112 of attacks on email, do not offer full end-to-end protection to the 113 header section and are not capable of providing privacy for the 114 information contained therein. 116 The need for means of Data Minimization, which includes data 117 spareness and hiding all technically concealable information whenever 118 possible, has grown in importance over the past several years. 120 A standard for end-to-end protection of the email header section 121 exists for S/MIME version 3.1 and later. (cf. [RFC8551]): 123 In order to protect outer, non-content-related message header 124 fields (for instance, the "Subject", "To", "From", and "Cc" 125 fields), the sending client MAY wrap a full MIME message in a 126 message/rfc822 wrapper in order to apply S/MIME security services 127 to these header fields. 129 No mechanism for header protection (HP) has been standardized for PGP 130 (Pretty Good Privacy) [RFC4880] yet. 132 Several varying implementations of end-to-end protections for email 133 header sections exist, though the total number of such 134 implementations appears to be rather low. 136 Some LAMPS WG participants expressed the opinion that whatever 137 mechanism will be chosen, it should not be limited to S/MIME, but 138 also applicable to PGP/MIME. 140 This document describes the problem statement (Section 2), generic 141 use cases (Section 3) and requirements for Header Protection 142 (Section 4). In Appendix A, possible solutions to address the 143 challenge and some best practices are collected. In any case, the 144 final solution is to be determined by the IETF LAMPS WG. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 1.2. Terms 154 The following terms are defined for the scope of this document: 156 o Header Protection (HP): cryptographic protection of email Header 157 Sections for signatures and encryption 159 o Header Field (HF): cf. [RFC5322] 161 o Header Section (HS): cf. [RFC5322] 163 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 164 form of active wiretapping attack in which the attacker intercepts 165 and selectively modifies communicated data to masquerade as one or 166 more of the entities involved in a communication association." 168 o 'Signature and encryption', 'signature only' or 'encryption only' 169 are further explained in Section 3.2. 171 2. Problem Statement 173 The LAMPS charter contains the following Work Item: 175 Update the specification for the cryptographic protection of email 176 headers - both for signatures and encryption - to improve the 177 implementation situation with respect to privacy, security, 178 usability and interoperability in cryptographically-protected 179 electronic mail. Most current implementations of 180 cryptographically-protected electronic mail protect only the body 181 of the message, which leaves significant room for attacks against 182 otherwise-protected messages. 184 In the following a set of challenges to be addressed: 186 [[ TODO: enhance this section, add more items to the following ]] 188 2.1. Privacy 190 o Data Minimization, which includes data spareness and hiding all 191 technically concealable information whenever possible 193 2.2. Security 195 o MITM attacks (cf. [RFC4949]) 197 2.3. Usability 199 o User interaction / User experience 201 2.4. Interoperability 203 o Interoperability with [RFC8551] implementations 205 3. Use Cases 207 In the following a list of the generic use cases that need to be 208 addressed for messages with Header Protection (HP). These use cases 209 apply independently of whether S/MIME, PGP/MIME or any other 210 technology is used to achieve HP. 212 3.1. Interactions 214 The main interaction case for Header Protection (HP) is: 216 1) Both peers (sending and receiving side) fully support HP 218 For backward compatibility of legacy clients - unaware of any HP - 219 the following intermediate interactions need to be considered as 220 well: 222 2) The sending side fully supports HP, while the receiving side does 223 not support any HP 225 3) The sending side does not support any HP, while the receiving 226 side fully supports HP 228 4) Neither the sending side nor the receiving side supports any HP 229 (trivial case) 231 The following intermediate use cases may need to be considered as 232 well for backward compatibility with legacy HP systems, such as 233 S/MIME version 3.1 and later (cf. [RFC8551]), in the following 234 designated as legacy HP: 236 5) The sending side fully supports HP, while the receiving side 237 supports legacy HP only 239 6) The sending side supports legacy HP only, while the receiving side 240 fully supports HP 242 7) Both peers (sending and receiving side) support legacy HP only 244 8) The sending side supports legacy HP only, while the receiving side 245 does not support any HP 247 9) The sending side does not support any HP, while the receiving side 248 supports legacy HP only 250 Note: It is to be decided whether to ensure legacy HP systems do not 251 conflict with any new solution for HP at all or whether (and to which 252 degree) backward compatibility to legacy HP systems shall be 253 maintained. 255 [[ TODO: Decide in which form legacy HP requirements should remain in 256 this document. ]] 258 3.2. Protection Levels 260 The following protection levels need to be considered: 262 a) Signature and encryption 264 Messages containing a cryptographic signature which are also 265 encrypted. 267 Sending and receiving side SHOULD implement 'signature and 268 encryption', which is the default to use on the sending side. 270 b) Signature only 272 Messages containing a cryptographic signature, but which no 273 encryption is applied to. 275 Certain implementations MAY decide to send 'signature only' messages, 276 depending on the circumstances and customer requirements. Sending 277 and Receiving sides SHOULD implement 'signature only'. 279 c) Encryption only 281 Messages that encryption is applied to which do not contain a 282 cryptographic signature. 284 'Encryption only' is NOT RECOMMENDED on the sending side, however the 285 receiving side needs certain guidelines on how to process received 286 'encrypted only' messages 288 4. Requirements 290 The following is a list of requirements that need to be addressed 291 independently of whether S/MIME, PGP/MIME or any other technology is 292 used to apply HP to. 294 4.1. General Requirements 296 Note: This subsection lists the requirements to address use case 1) 297 (cf. Section 3.1). 299 G1: Define the HP format for all protection levels (cf. above), which 300 includes MIME structure, Content-Type (including all parameters, 301 such as "charset" and "name"), Content-Disposition (including all 302 parameters, such as "filename"), and Content-Transfer-Encoding. 304 G2: To foster wide implementation of the new solution, it shall be 305 easily implementable. Unless needed for maximizing protection and 306 privacy, existing implementations shall not require substantial 307 changes in the existing code base. In particular also MIME 308 libraries widely used shall not need to be changed to comply with 309 the new mechanism for HP. 311 G3: There SHOULD be a single format that covers all protection levels 312 (cf. above). 314 [[ TODO: Should this one remain in the document?]] 316 G4: Ensure that man-in-the-middle attack (MITM, cf. [RFC4949]), in 317 particular downgrade attacks, are mitigated to the greatest extent 318 possible. 320 4.1.1. Sending Side 321 GS1: Determine which Header Fields (HFs) should or must be protected 322 for 'signature only' emails at a minimum. 324 GS2: Determine which HFs should or must be sent in clear text (i.e., 325 included in the outer header) for emails with (signature and) 326 encryption applied. 328 GS3: Determine which HFs should not or must not be sent in clear text 329 (i.e., not be included in the outer header) of an email with 330 (signature and) encryption applied. 332 GS4: Determine which HFs to not include to any HP part (e.g. Bcc). 334 4.1.2. Receiving Side 336 GR1: Determine how HFs should be displayed to the user in case of 337 conflicting information between the protected and unprotected 338 HFs. 340 GR2: Ensure that man-in-the-middle attacks (MITM, cf. [RFC4949]), in 341 particular downgrade attacks, can be detected. 343 GR3: Define how emails that 'encryption only' was applied to 344 are to be treated. 346 4.2. Additional Requirements for Backward-Compatibility With Legacy 347 Clients Unaware of Header Protection 349 Note: This sub-section addresses the use cases 2) - 4) (cf. 350 Section 3.1) 352 B1: Define a means to distinguish between forwarded emails and 353 encapsulated emails using new HP mechanism. 355 4.2.1. Sending side 357 BS1: Define how full HP support can be indicated to outgoing 358 emails. 360 BS2: Define how full HP support of the receiver can be detected or 361 derived. 363 BS3: Ensure a HP-unaware receiving side easily can display the 364 "Subject" HF to the user. 366 4.2.2. Receiving side 368 BR1: Define how full HP support can be detected in incoming emails. 370 4.3. Additional Requirements for Backward-Compatibility with Legacy 371 Header Protection Systems (if supported) 373 Note: This sub-section addresses the use cases 5) - 9) (cf. 374 Section 3.1). 376 LS1: Depending on the solution, define a means to distinguish between 377 forwarded emails, legacy encapsulated emails, and 378 encapsulated emails using new HP mechanism. 380 LS2: The solution should be backward compatible to existing solutions 381 and aim to minimize the implementation effort to include support 382 for existing solutions. 384 4.3.1. Sending Side 386 LSS1: Determine how legacy HP support can be indicated to outgoing 387 emails. 389 LSS2: Determine how legacy HP support of the receiver can be detected 390 or derived. 392 4.3.2. Receiving Side 394 LSR1: Determine how legacy HP support can be detected in incoming 395 emails. 397 5. Security Considerations 399 This document talks about UI considerations, including security 400 considerations, when processing messages protecting Header Fields. 401 One of the goals of this document is to specify UI for displaying 402 such messages which is less confusing/misleading for the end-user and 403 thus more secure. 405 The document does not define a new protocol, and thus does not create 406 any new security concerns not already covered by S/MIME [RFC8551], 407 MIME [RFC2045] and Email [RFC5322] in general. 409 6. Privacy Considerations 411 [[ TODO ]] 413 7. IANA Considerations 415 This document requests no action from IANA. 417 [[ RFC Editor: This section may be removed before publication. ]] 419 8. Acknowledgments 421 The authors would like to thank the following people who have 422 provided helpful comments and suggestions for this document: David 423 Wilson, Kelly Bristol, Robert Williams, Steve Kille, and Wei Chuang. 425 Essential parts of [I-D.luck-lamps-pep-header-protection] have been 426 merged into this document. Special thanks to its author Claudio 427 Luck. For further Acknowledgments, please refer to Acknowledgments 428 section of [I-D.luck-lamps-pep-header-protection]. 430 David Wilson came up with the idea of defining a new Content-Type 431 header field parameter to distinguish forwarded messages from inner 432 header field protection constructs. 434 9. References 436 9.1. Normative References 438 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 439 Extensions (MIME) Part One: Format of Internet Message 440 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 441 . 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 449 DOI 10.17487/RFC5322, October 2008, 450 . 452 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 453 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 454 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 455 April 2019, . 457 9.2. Informative References 459 [I-D.luck-lamps-pep-header-protection] 460 Luck, C., "pretty Easy privacy (pEp): Progressive Header 461 Disclosure", draft-luck-lamps-pep-header-protection-03 462 (work in progress), July 2019. 464 [I-D.marques-pep-email] 465 Marques, H., "pretty Easy privacy (pEp): Email Formats and 466 Protocols", draft-marques-pep-email-02 (work in progress), 467 October 2018. 469 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 470 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 471 . 473 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 474 Thayer, "OpenPGP Message Format", RFC 4880, 475 DOI 10.17487/RFC4880, November 2007, 476 . 478 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 479 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 480 . 482 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 483 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 484 RFC 6376, DOI 10.17487/RFC6376, September 2011, 485 . 487 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 488 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 489 2012, . 491 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 492 Authorizing Use of Domains in Email, Version 1", RFC 7208, 493 DOI 10.17487/RFC7208, April 2014, 494 . 496 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 497 Message Authentication, Reporting, and Conformance 498 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 499 . 501 Appendix A. Implementation Considerations 503 [[ Note: Please be advised that this part of the document is early 504 work-in-progress. ]] 506 This Appendix A contains additional information and considerations 507 regarding the implementation. Although not (strictly) part of the 508 requirements, this is useful to better understand them. Parts of the 509 text in this Appendix A will likely be moved to the upcoming 510 implementation document. 512 A.1. Options to Achieve Header Protection 514 The following are current options for addressing Email Header 515 Protection. The IETF LAMPS WG may choose from these options in order 516 to update [RFC8551]. 518 A.1.1. Option 1: Memory Hole 520 The Memory Hole approach works by copying the normal message header 521 fields into the MIME header section of the top level protected body 522 part. Since the MIME body part header section is itself covered by 523 the protection mechanisms (signature and/or encryption) it shares the 524 protections of the message body. 526 [[ TODO: add more information on memory hole ]] 528 A.1.2. Option 2: Wrapping with message/rfc822 or message/global 530 Wrapping with message/rfc822 (or message/global) works by copying the 531 normal message header fields into the MIME header section of the top 532 level protect body part 534 [[ TODO: consider rephrasing, as not only the header fields is 535 copied, but also the content.]] 537 and then prepending them with "Content-Type: message/rfc822; 538 forwarded=no\r\n" or "Content-Type: message/global; 539 forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF 540 (see also Appendix A.1.2.1). Since the MIME body part header section 541 is itself covered by the protection mechanisms (signature and/or 542 encryption) it shares the protections of the message body. 544 A.1.2.1. Content-Type Parameter "forwarded" 546 This section outlines how the new "forwarded" Content-Type header 547 field parameter could be defined (probably in a separate document) 548 and how header section wrapping works: 550 This document defines a new Content-Type header field parameter 551 [RFC2045] with name "forwarded". The parameter value is case- 552 insensitive and can be either "yes" or "no". (The default value 553 being "yes"). The parameter is only meaningful with media type 554 "message/rfc822" and "message/global" [RFC6532] when used within 555 S/MIME or PGP/MIME signed or encrypted body parts. The value "yes" 556 means that the message nested inside "message/rfc822" ("message/ 557 global") is a forwarded message and not a construct created solely to 558 protect the inner header section. 560 Instructions in [RFC8551] describing how to protect the Email message 561 header section [RFC5322], by wrapping the message inside a message/ 562 rfc822 container [RFC2045] are thus updated to read: 564 In order to protect outer, non-content-related message header 565 fields (for instance, the "Subject", "To", "From", and "Cc" 566 fields), the sending client MAY wrap a full MIME message in a 567 message/rfc822 wrapper in order to apply S/MIME security services 568 to these header fields. It is up to the receiving client to 569 decide how to present this "inner" header section along with the 570 unprotected "outer" header section. 572 When an S/MIME message is received, if the top-level protected 573 MIME entity has a Content-Type of message/rfc822 or message/global 574 without the "forwarded" parameter or with the "forwarded" 575 parameter set to "no", it can be assumed that the intent was to 576 provide header protection. This entity SHOULD be presented as the 577 top-level message, taking into account header section merging 578 issues as previously discussed. 580 A.1.3. Option 2.1: Progressive Header Disclosure 582 This option is similar to Option 2 (cf. Appendix A.1.2). It also 583 makes use the Content-Type parameter "forwarded" (cf. 584 Appendix A.1.2.1). 586 pEp for email [I-D.marques-pep-email] defines a fixed MIME structure 587 for its innermost message structure. Security comes just next after 588 privacy in pEp, for which reason the application of signatures 589 without encryption to messages in transit is not considered 590 purposeful. pEp for email, either expects to transfer messages in 591 cleartext without signature or encryption, or transfer them encrypted 592 and with enclosed signature and necessary public keys so that replies 593 can be immediately upgraded to encrypted messages. 595 The pEp message format is equivalent to the S/MIME standard in 596 ensuring header protection, in that the whole message is protected 597 instead, by wrapping it and providing cryptographic services to the 598 whole original message. However, for the purpose of allowing the 599 insertion of public keys, the root entity of the protected message is 600 thus nested once more into an additional multipart/mixed MIME entity. 601 The current pEp proposal is for PGP/MIME, while an extension to 602 S/MIME is also on the roadmap. 604 pEp has also implemented the above (in Appendix A.1.2.1) described 605 Content-Type parameter "forwarded" to distinguish between 606 encapsulated and forwarded emails. 608 More information on progressive header disclosure can be found in 609 [I-D.luck-lamps-pep-header-protection]. 611 A.1.4. Examples 613 Examples in subsequent sections assume that an email client is trying 614 to protect (sign) the following initial message: 616 Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 617 From: "Alexey Melnikov" 618 Message-ID: 619 MIME-Version: 1.0 620 MMHS-Primary-Precedence: 3 621 Subject: Meeting at my place 622 To: somebody@example.net 623 X-Mailer: Isode Harrier Web Server 624 Content-Type: text/plain; charset=us-ascii 626 This is an important message that I don't want to be modified. 628 Without message header protection the corresponding signed message 629 might look like this. (Lines prepended by "O: " are the outer 630 header.) 632 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 633 O: Message-ID: 634 O: Subject: Meeting at my place 635 O: From: "Alexey Melnikov" 636 O: MIME-Version: 1.0 637 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 638 O: protocol="application/pkcs7-signature"; 639 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 641 This is a multipart message in MIME format. 642 --.cbe16d2a-e1a3-4220-b821-38348fc97237 643 Content-Type: text/plain; charset=us-ascii 645 This is an important message that I don't want to be modified. 647 --.cbe16d2a-e1a3-4220-b821-38348fc97237 648 Content-Transfer-Encoding: base64 649 Content-Type: application/pkcs7-signature 651 [[base-64 encoded signature]] 653 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 655 A.1.4.1. Option 1: Memory Hole 657 The following example demonstrates how header section and payload of 658 a protect body part might look like. For example, this will be the 659 first body part of a multipart/signed message or the signed and/or 660 encrypted payload of the application/pkcs7-mime body part. Lines 661 prepended by "O: " are the outer header section. Lines prepended by 662 "I: " are the inner header section. 664 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 665 O: Message-ID: 666 O: Subject: Meeting at my place 667 O: From: "Alexey Melnikov" 668 O: MIME-Version: 1.0 669 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 670 O: protocol="application/pkcs7-signature"; 671 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 673 This is a multipart message in MIME format. 674 --.cbe16d2a-e1a3-4220-b821-38348fc97237 675 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 676 I: From: "Alexey Melnikov" 677 I: Message-ID: 678 I: MIME-Version: 1.0 679 I: MMHS-Primary-Precedence: 3 680 I: Subject: Meeting at my place 681 I: To: somebody@example.net 682 I: X-Mailer: Isode Harrier Web Server 683 I: Content-Type: text/plain; charset=us-ascii 685 This is an important message that I don't want to be modified. 687 --.cbe16d2a-e1a3-4220-b821-38348fc97237 688 Content-Transfer-Encoding: base64 689 Content-Type: application/pkcs7-signature 691 [[base-64 encoded signature]] 693 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 695 [[ TODO (AM): HB: Not sure whether the Outer Subject HF is replaced 696 by "Encrypted Message" (or alike). Please verify. ]] 698 A.1.4.2. Option 2: Wrapping with message/rfc822 or message/global 700 The following example demonstrates how header section and payload of 701 a protect body part might look like. For example, this will be the 702 first body part of a multipart/signed message or the signed and/or 703 encrypted payload of the application/pkcs7-mime body part. Lines 704 prepended by "O: " are the outer header section. Lines prepended by 705 "I: " are the inner header section. Lines prepended by "W: " are the 706 wrapper. 708 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 709 O: Message-ID: 710 O: Subject: Meeting at my place 711 O: From: "Alexey Melnikov" 712 O: MIME-Version: 1.0 713 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 714 O: protocol="application/pkcs7-signature"; 715 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 717 This is a multipart message in MIME format. 718 --.cbe16d2a-e1a3-4220-b821-38348fc97237 719 W: Content-Type: message/rfc822; forwarded=no 720 W: 721 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 722 I: From: "Alexey Melnikov" 723 I: Message-ID: 724 I: MIME-Version: 1.0 725 I: MMHS-Primary-Precedence: 3 726 I: Subject: Meeting at my place 727 I: To: somebody@example.net 728 I: X-Mailer: Isode Harrier Web Server 729 I: Content-Type: text/plain; charset=us-ascii 731 This is an important message that I don't want to be modified. 733 --.cbe16d2a-e1a3-4220-b821-38348fc97237 734 Content-Transfer-Encoding: base64 735 Content-Type: application/pkcs7-signature 737 [[base-64 encoded signature]] 739 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 741 A.1.4.3. Option 2.1 Progressive Header Disclosure 743 The following example demonstrates how header section and payload of 744 a protect body part might look like. For example, this will be the 745 first body part of a multipart/signed message or the signed and 746 encrypted payload of the application/pkcs7-mime body part. Lines 747 prepended by "O: " are the outer header section. Lines prepended by 748 "I: " are the inner header section. Lines prepended by "W: " are the 749 wrapper. 751 The main difference compared to Option 2 is an additional multipart/ 752 mixed Content-Type containing the original message (as a whole) and 753 the public key (of the sender). 755 Note: This example is derived from the pEp's PGP/MIME implementation 756 and adjusted to the above S/MIME examples. The pEp implementations 757 do not support S/MIME yet; therefore the following can serve no more 758 as for illustrative purpose. Specific examples can be found in 759 [I-D.luck-lamps-pep-header-protection]. 761 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 762 O: Message-ID: 763 O: Subject: Meeting at my place 764 O: From: "Alexey Melnikov" 765 W: MIME-Version: 1.0 766 W: Content-Type: multipart/mixed; 767 W: boundary="6b8b4567327b23c6643c986966334873" 768 W: 769 W: --6b8b4567327b23c6643c986966334873 770 W: Content-Type: message/rfc822; forwarded="no" 771 W: 772 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 773 I: Message-ID: 774 I: Subject: Meeting at my place 775 I: From: "Alexey Melnikov" 776 I: MIME-Version: 1.0 777 I: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 778 I: protocol="application/pkcs7-signature"; 779 I: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 781 This is a multipart message in MIME format. 782 --.cbe16d2a-e1a3-4220-b821-38348fc97237 783 Content-Type: text/plain; charset=us-ascii 785 This is an important message that I don't want to be modified. 787 --.cbe16d2a-e1a3-4220-b821-38348fc97237 788 Content-Transfer-Encoding: base64 789 Content-Type: application/pkcs7-signature 791 [[base-64 encoded signature]] 793 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 794 W: --6b8b4567327b23c6643c986966334873 795 W: Content-Type: application/pgp-keys 796 W: Content-Disposition: attachment; filename="pEpkey.asc" 797 W: 798 -----BEGIN PGP PUBLIC KEY BLOCK----- 799 ... 800 -----END PGP PUBLIC KEY BLOCK----- 801 W: 802 W: --6b8b4567327b23c6643c986966334873-- 804 A.2. Sending Side Considerations 806 A.2.1. Candidate Header Fields for Header Protection 808 [[ TODO: This section is very early stage and needs more work. ]] 810 For a 'signature only' (cf. Section 3.2) message, it is RECOMMENDED 811 that all "outer" header fields are identical to the "inner" protected 812 header fields. This would mean that all header fields are signed. 813 In this case, the "outer" header fields simply match the protected 814 header fields. And in the case that the "outer" header fields 815 differ, they can simply be replaced with their protected versions 816 when displayed to the user. 818 [[ TODO: Decide whether "Bcc" header field should be excluded. Also 819 verify whether this requirement applies generally or just for 820 specific implementations. ]] 822 When generating S/MIME messages with applied (signature and) 823 encryption to protect header fields: 825 1. If a header field is being encrypted because it is sensitive, its 826 true value MUST NOT be included in the outer header. If the 827 header field is mandatory according to [RFC5322], a stub value 828 (or a value indicating that the outer value is not to be used) is 829 to be included in the outer header section. 831 2. The outer header section SHOULD be minimal in order to avoid 832 disclosure of confidential information. It is recommended that 833 the outer header section only contains "Date" (set to the same 834 value as in the inner header field, or, if the Date value is also 835 sensitive, to Monday 9am of the same week), possibly "Subject" 836 and "To"/"Cc" header fields. ("From", "Date", and at least one 837 destination header field is mandatory as per [RFC5322].) In 838 particular, Keywords, In-Reply-To and References header fields 839 SHOULD NOT be included in the outer header; "To" and "Cc" header 840 fields should be omitted and replaced with "Bcc: undisclosed- 841 recipients;". 843 But note that having key header fields duplicated in the outer 844 header is convenient for many message stores (e.g. IMAP) and 845 clients that can't decode S/MIME encrypted messages. In 846 particular, Subject/To/Cc/Bcc/Date header field values are 847 returned in IMAP ENVELOPE FETCH data item [RFC3501], which is 848 frequently used by IMAP clients in order to avoid parsing message 849 header. 851 3. The "Subject" header field value of the outer header section 852 SHOULD either be identical to the inner "Subject" header field 853 value, or contain a clear indication that the outer value is not 854 to be used for display (the inner header field value would 855 contain the true value). 857 Note that recommendations listed above typically only apply to non 858 MIME header fields (header fields with names not starting with 859 "Content-" prefix), but there are exceptions, e.g. Content-Language. 861 Note that the above recommendations can also negatively affect anti- 862 spam processing. 864 Messages containing at least one recipient address in the Bcc header 865 field may appear in up to three different variants: 867 1. The message for the recipient addresses listed in To or Cc header 868 fields, which must not include the Bcc header field neither for 869 signature calculation nor for encryption. 871 2. The message(s) sent to the recipient addresses in the Bcc header 872 field, which depends on the implementation: 874 a) One message for each recipient in the Bcc header field 875 separately with a Bcc header field containing only the address of 876 the recipient it is sent to 878 b) The same message for each recipient in the Bcc header field 879 with a Bcc header field containing an indication such as 880 "Undisclosed recipients" (but no addressees) 882 c) The same message for each recipient in the Bcc header field 883 which does not include a Bcc header field (this message is 884 identical to 1. / cf. above) 886 3. The message stored in the 'Sent'-Folder of the sender, which 887 usually contains the Bcc unchanged from the original message, 888 i.e. with all recipient addresses. 890 Regarding the Bcc header field there should be no difference between 891 the inner and the outer header section. 893 A.3. Receiving Side Considerations 894 A.3.1. Which Header Fields to Display to User 896 When displaying S/MIME messages which protect header fields 897 (independent of which protection level 'signature and encryption', 898 'signature only' or 'encryption only' is applied to (cf. 899 Section 3.2): 901 1. The outer header fields might be tampered with, so a receiving 902 client SHOULD ignore them, unless they are protected in some 903 other way(*). If a header field is present in the inner header, 904 only the inner header field value MUST be displayed (and the 905 corresponding outer value must be ignored). If a particular 906 header field is only present in the outer header, it MAY be 907 ignored (not displayed) or it MAY be displayed with a clear 908 indicator that it is not trustworthy(*). 910 (*) - this only applies if the header field is not protected is 911 some other way, for example with a DKIM signature that validates 912 and is trusted. 914 A.3.2. Mail User Agent Algorithm for deciding which version of a header 915 field to display 917 [[ TODO: describe how to recurse to find the innermost protected root 918 body part, extract header fields from it and propagate them to the 919 top level. This should also work for triple-wrapped messages.]] 921 Appendix B. Document Changelog 923 [[ RFC Editor: This section is to be removed before publication ]] 925 o draft-ietf-lamps-header-protection-requirements-00 927 * Initial version 929 o draft-ietf-lamps-header-protection-requirements-01 931 * Moved Implementation Considerations to Appendix (HB) 933 * Shortened abstract (HB) 935 * Many editorial changes, e.g., replaced "content-type" with 936 "Content-Type". (HB) 938 * Added example for Option 2.1 / pEp (HB) 940 * Added (short) definition of Header Protection (HB) 941 * Added more information regarding Bcc (feedback IETF-105) (HB) 943 * Simplified GS3 (HB) 945 * Added GR3 (HB) 947 Appendix C. Open Issues 949 [[ RFC Editor: This section should be empty and is to be removed 950 before publication. ]] 952 o Enhance Introduction and Problem Statement sections 954 o Decide in which form legacy HP requirements should remain in this 955 document 957 o Improve definitions in Section 3.2 959 o Should requirement G3 remain? If you consider improve / rewrite 960 it. 962 o Add more text on Memory Hole 964 o Rephrase Appendix A.1.2 966 o Resolve question regarding Bcc in Appendix A.2.1 968 o Rewrite Appendix A.2.1 970 o Write Appendix A.3.2 972 o Correct terminology for Header(s) and Header Fields throughout the 973 document (editorial). 975 * Header: Whole Header Section of the message 977 * Header Field: Part / single Line inside a Header (Section) 979 o Replace "email" by "email message" as needed 981 Authors' Addresses 982 Alexey Melnikov 983 Isode Ltd 984 14 Castle Mews 985 Hampton, Middlesex TW12 2NP 986 UK 988 Email: alexey.melnikov@isode.com 990 Bernie Hoeneisen 991 Ucom Standards Track Solutions GmbH 992 CH-8046 Zuerich 993 Switzerland 995 Phone: +41 44 500 52 40 996 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 997 URI: https://ucom.ch/