idnits 2.17.1 draft-ietf-lamps-header-protection-03.txt: -(1114): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 50 instances of lines with non-ascii characters in the document. 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 (22 February 2021) is 1158 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DKG' is mentioned on line 2039, but not defined == Missing Reference: 'HB' is mentioned on line 2057, but not defined ** Downref: Normative reference to an Informational draft: draft-dkg-lamps-e2e-mail-guidance (ref. 'I-D.dkg-lamps-e2e-mail-guidance') ** Downref: Normative reference to an Informational draft: draft-ietf-lamps-header-protection-requirements (ref. 'I-D.ietf-lamps-header-protection-requirements') == Outdated reference: A later version (-02) exists of draft-pep-email-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group D.K. Gillmor 3 Internet-Draft American Civil Liberties Union 4 Intended status: Standards Track B. Hoeneisen 5 Expires: 26 August 2021 pEp Foundation 6 A. Melnikov 7 Isode Ltd 8 22 February 2021 10 Header Protection for S/MIME 11 draft-ietf-lamps-header-protection-03 13 Abstract 15 S/MIME version 3.1 has introduced a feasible standardized option to 16 accomplish Header Protection. However, few implementations generate 17 messages using this structure, and several legacy and non-legacy 18 implementations have revealed rendering issues at the receiving side. 19 Clearer specifications regarding message processing, particularly 20 with respect to header sections, are needed in order to resolve these 21 rendering issues. Some mail user agents are also sending and 22 receiving cryptographically-protected message headers using a 23 different structure. 25 In order to help implementers to correctly compose and render email 26 messages with Header Protection, this document updates S/MIME Header 27 Protection specifications with additional guidance on MIME format, 28 sender and receiver processing. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 26 August 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Two Schemes of Protected Headers . . . . . . . . . . . . 4 65 1.2. Problems with Wrapped Messages . . . . . . . . . . . . . 4 66 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.4. Other Protocols to Protect Email Headers . . . . . . . . 5 68 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6 69 1.6. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 71 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 9 73 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9 74 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 9 75 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 10 78 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 10 79 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 12 80 3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 12 81 3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 12 82 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 13 84 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 13 85 4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 16 86 4.1.3. Default Header Confidentiality Policy . . . . . . . . 21 87 4.1.4. Receiving Side . . . . . . . . . . . . . . . . . . . 22 88 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 30 89 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 31 90 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 31 91 5. Usability Considerations . . . . . . . . . . . . . . . . . . 32 92 5.1. Mixed Protections Within a Message Are Hard To 93 Understand . . . . . . . . . . . . . . . . . . . . . . . 32 95 5.2. Users Should Not Have To Choose a Header Confidentiality 96 Policy . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 98 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 32 103 10.2. Informative References . . . . . . . . . . . . . . . . . 33 104 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 105 A.1. Wrapped Message examples . . . . . . . . . . . . . . . . 35 106 A.1.1. Wrapped Message: signed-only, with PKCS7 107 signedData . . . . . . . . . . . . . . . . . . . . . 35 108 A.1.2. Wrapped Message: signed-only, using multipart/ 109 signed . . . . . . . . . . . . . . . . . . . . . . . 35 110 A.1.3. Wrapped Message: signed-and-encrypted . . . . . . . . 35 111 A.2. Injected Headers examples . . . . . . . . . . . . . . . . 35 112 A.2.1. Injected Headers: signed-only, with PKCS7 113 signedData . . . . . . . . . . . . . . . . . . . . . 35 114 A.2.2. Injected Headers: signed-only, using multipart/ 115 signed . . . . . . . . . . . . . . . . . . . . . . . 36 116 A.2.3. Injected Headers: signed-and-encrypted with Legacy 117 Display part . . . . . . . . . . . . . . . . . . . . 36 118 A.2.4. Injected Headers: signed-and-encrypted without Legacy 119 Display part . . . . . . . . . . . . . . . . . . . . 36 120 A.3. Messages without Header Protection . . . . . . . . . . . 36 121 A.3.1. Unprotected Headers: signed-only, with PKCS7 122 signedData . . . . . . . . . . . . . . . . . . . . . 36 123 A.3.2. Unprotected Headers: signed-only, using multipart/ 124 signed . . . . . . . . . . . . . . . . . . . . . . . 36 125 A.3.3. Unprotected Headers: signed-and-encrypted . . . . . . 36 126 Appendix B. Additional information . . . . . . . . . . . . . . . 36 127 B.1. Stored Variants of Messages with Bcc . . . . . . . . . . 36 128 Appendix C. Text Moved from Above . . . . . . . . . . . . . . . 37 129 C.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 37 130 C.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 37 131 C.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 40 132 Appendix D. Document Considerations . . . . . . . . . . . . . . 44 133 Appendix E. Document Changelog . . . . . . . . . . . . . . . . . 45 134 Appendix F. Open Issues . . . . . . . . . . . . . . . . . . . . 46 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 137 1. Introduction 139 Privacy and security issues regarding email Header Protection in S/ 140 MIME have been identified for some time. Most current 141 implementations of cryptographically-protected electronic mail 142 protect only the body of the message, which leaves significant room 143 for attacks against otherwise-protected messages. For example, lack 144 of header protection allows an attacker to substitute the message 145 subject and/or author. 147 This document describes two different structures for how message 148 headers can be cryptographically protected, and provides guidance for 149 implementers of MUAs that generate and interpret such messages. It 150 takes particular care to ensure that messages interact reasonably 151 well with legacy MUAs. 153 1.1. Two Schemes of Protected Headers 155 Unfortunately, there are two different schemes for cryptographically- 156 protected email headers that may be in use on the Internet today. 157 This document addresses them both and provides guidance to 158 implementers. 160 One scheme is the form specified in S/MIME 3.1 and later, which 161 involves wrapping a "message/rfc822" MIME object with a Cryptographic 162 Envelope. This document calls this scheme "Wrapped Message", and it 163 is documented in more detail in [RFC8551]. Experience has shown that 164 this form does not interact well with some legacy MUAs (see 165 Section 1.2). 167 Consequently, another form of header protection is produced and 168 consumed by some MUAs, where the protected headers are placed 169 directly on the Cryptographic Payload, without using an intervening 170 "message/*" MIME object. This document calls this scheme "Injected 171 Headers", and it is documented in more detail in 172 [I-D.autocrypt-lamps-protected-headers]. 174 1.2. Problems with Wrapped Messages 176 Several legacy MUAs have revealed rendering issues when dealing with 177 a message with headers protected by the Wrapped Message scheme. In 178 some cases the user sees an attachment suggesting a forwarded email 179 message, which -- in fact -- contains the protected email message 180 that should be rendered directly. For these cases, the user can 181 click on the attachment to view the protected message. However, 182 there have also been reports of email clients displaying garbled 183 text, or sometimes nothing at all. In those cases the email clients 184 on the receiving side are (most likely) not fully MIME-capable. 186 The following shortcomings have been identified to cause these 187 issues: 189 * Broken or incomplete implementations 191 * Lack of a simple means to distinguish "forwarded message" and 192 "wrapped message" (for the sake of Header Protection) 194 * Not enough guidance with respect to handling of Header Fields on 195 both the sending and the receiving side 197 1.3. Motivation 199 Furthermore, the need (technical) Data Minimization, which includes 200 data sparseness and hiding all technically concealable information, 201 has grown in importance over the past several years. In addition, 202 backwards compatibility must be considered when it is possible to do 203 so without compromising privacy and security. 205 No mechanism for Header Protection has been standardized for PGP/MIME 206 (Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have 207 implemented ad-hoc header-protection, and would like to see a 208 specification that is applicable to both S/MIME and PGP/MIME. 210 This document describes the problem statement (Section 2), generic 211 use cases (Section 3) and the specification for Header Protection 212 (Section 4) with guidance on MIME format, sender and receiver 213 processing . 215 [I-D.ietf-lamps-header-protection-requirements] defines the 216 requirements that this specification is based on. 218 This document is in an early draft state and contains a proposal on 219 which to base future discussions of this topic. In any case, the 220 final mechanism is to be determined by the IETF LAMPS WG. 222 1.4. Other Protocols to Protect Email Headers 224 A range of protocols for the protection of electronic mail (email) 225 exists, which allows one to assess the authenticity and integrity of 226 the email headers section or selected Header Fields from the domain- 227 level perspective, specifically DomainKeys Identified Mail (DKIM) 228 [RFC6376], as used by Domain-based Message Authentication, Reporting, 229 and Conformance (DMARC) [RFC7489]. These protocols provide a domain- 230 based reputation mechanism that can be used to mitigate some forms of 231 unsolicited email (spam). At the same time, these protocols can 232 provide a level of cryptographic integrity and authenticity for some 233 headers, depending on how they are used. However, integrity 234 protection and proof of authenticity are both tied to the domain name 235 of the sending e-mail address, not the sending address itself, so 236 these protocols do not provide end-to-end protection, and are 237 incapable of providing any form of confidentiality. 239 1.5. Requirements Language 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 243 document are to be interpreted as described in [RFC2119]. 245 1.6. Terms 247 The following terms are defined for the scope of this document: 249 * Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 250 form of active wiretapping attack in which the attacker intercepts 251 and selectively modifies communicated data to masquerade as one or 252 more of the entities involved in a communication association." 254 Note: Historically, MITM has stood for '_Man_-in-the-middle'. 255 However, to indicate that the entity in the middle is not always a 256 human attacker, MITM can also stand for 'Machine-in-the-middle' or 257 'Meddler-in-the-middle'. 259 * S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. 260 [RFC8551]) 262 * PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) 264 * Message: An Email Message consisting of Header Fields 265 (collectively called "the Header Section of the message") 266 followed, optionally, by a Body; cf. [RFC5322]. 268 Note: To avoid ambiguity, this document does not use the terms 269 "Header" or "Headers" in isolation, but instead always uses 270 "Header Field" to refer to the individual field and "Header 271 Section" to refer to the entire collection; cf. [RFC5322]. 273 * Header Field (HF): cf. [RFC5322] Header Fields are lines beginning 274 with a field name, followed by a colon (":"), followed by a field 275 body (value), and terminated by CRLF. 277 * Header Section (HS): The Header Section is a sequence of lines of 278 characters with special syntax as defined in [RFC5322]. It is the 279 (top) section of a Message containing the Header Fields. 281 * Body: The Body is simply a sequence of bytes that follows the 282 Header Section and is separated from the Header Section by an 283 empty line (i.e., a line with nothing preceding the CRLF); cf 284 [RFC5322]. It is the (bottom) section of Message containing the 285 payload of a Message. Typically, the Body consists of a (possibly 286 multipart) MIME [RFC2045] construct. 288 * MIME Header Fields: Header Fields describing content of a MIME 289 entity [RFC2045], in particular the MIME structure. Each MIME 290 Header Field name starts with "Content-" prefix. 292 * MIME Header Section (part): The collection of MIME Header Fields. 293 "MIME Header Section" refers to a Header Sections that contains 294 only MIME Header Fields, whereas "MIME Header Section part" refers 295 to the MIME Header Fields of a Header Section that - in addition 296 to MIME Header Fields - also contains non-MIME Header Fields. 298 * Essential Header Fields (EHF): The minimum set of Header Fields an 299 Outer Message Header Section SHOULD contain; cf. Appendix C.1.2.5. 301 * Header Protection (HP): cryptographic protection of email Header 302 Sections (or parts of it) for signatures and/or encryption 304 * Protection Levels (PL): The level of protection applied to a 305 Message, e.g. 'signature and encryption' or 'signature only' (cf. 306 Section 3.2). 308 * Protected: Portions of a message that have had any Protection 309 Levels applied. 311 * Protected Message: A Message that has had any Protection Levels 312 applied. 314 * Unprotected: Portions of a Message that has had no Protection 315 Levels applied. 317 * Unprotected Message: A Message that has had no Protection Levels 318 applied. 320 * Submission Entity: The entity which executes further processing of 321 the Message (incl. transport towards the receiver), after 322 protection measures have been applied to the Message. 324 Note: The Submission Entity varies among implementations, mainly 325 depending on the stage where protection measures are applied: E.g. 326 a Message Submission Agent (MSA) [RFC6409] or another 327 (proprietary) solution. The latter is particularly relevant, if 328 protection is implemented as a plugin solution. Some 329 implementations may determine the destination recipients by 330 reading the To, Cc and Bcc Header Fields of the Outer Message. 332 * Original Message (OrigM): The Message to be protected before any 333 protection-related processing has been applied on the sending 334 side. If the source is not a "message/rfc822" Message, OrigM is 335 defined as the "virtual" Message that would be constructed for 336 sending it as unprotected email. 338 * Inner Message (InnerM): The Message to be protected which has had 339 wrapping and protection measures aapplied on the sending side OR 340 the resulting Message once decryption and unwrapping on the 341 receiving side has been performed. Typically, the Inner Message 342 is in clear text. The Inner Message is a subset of (or the same 343 as) the Original Message. The Inner Message must be the same on 344 the sending and the receiving side. 346 * Outer Message (OuterM): The Message as provided to the Submission 347 Entity or received from the last hop respectively. The Outer 348 Message normally differs on the sending and the receiving side 349 (e.g. new Header Fields are added by intermediary nodes). 351 * Receiving User Facing Message (RUFM): The Message used for 352 rendering at the receiving side. Typically this is the same as 353 the Inner Message. 355 * Data Minimization: Data sparseness and hiding of all technically 356 concealable information whenever possible. 358 * Cryptographic Layer, Cryptographic Payload, Cryptographic 359 Envelope, Structural Headers, and MUA are all used as defined in 360 [I-D.dkg-lamps-e2e-mail-guidance] 362 * User-Facing Headers are defined in 363 [I-D.autocrypt-lamps-protected-headers]. 365 * Legacy MUA: a MUA that does not understand protected headers as 366 described in this document. A Legacy Non-Crypto MUA is incapable 367 of doing any end-to-end cryptographic operations. A Legacy Crypto 368 MUA is capable of doing cryptographic operations, but does not 369 understand or generate protected headers. 371 * Wrapped Message: The protected headers scheme that uses the 372 mechanism described in [RFC8551], where the Cryptographic Payload 373 is a "message/rfc822" or "message/global" MIME object. 375 * Injected Headers: The protected headers scheme that uses the 376 mechanism described in [I-D.autocrypt-lamps-protected-headers], 377 where the protected headers are inserted on the Cryptographic 378 Payload directly. 380 * Header Confidentiality Policy: documented in Section 4.1.2.2 382 2. Problem Statement 384 The LAMPS charter contains the following Work Item: 386 Update the specification for the cryptographic protection of email 387 headers -- both for signatures and encryption -- to improve the 388 implementation situation with respect to privacy, security, 389 usability and interoperability in cryptographically-protected 390 electronic mail. Most current implementations of 391 cryptographically-protected electronic mail protect only the body 392 of the message, which leaves significant room for attacks against 393 otherwise-protected messages. 395 In the following a set of challenges to be addressed: 397 [[ TODO: Enhance this section, add more items to the following. ]] 399 2.1. Privacy 401 * (Technical) Data Minimization, which includes data sparseness and 402 hiding all technically concealable information whenever possible 404 2.2. Security 406 * Prevent MITM attacks (cf. [RFC4949]) 408 2.3. Usability 410 * Improved User interaction / User experience, in particular at the 411 receiving side 413 2.4. Interoperability 415 * Interoperability with [RFC8551] implementations 417 3. Use Cases 419 In the following, the reader can find a list of the generic use cases 420 that need to be addressed for Messages with Header Protection (HP). 421 These use cases apply regardless of technology (S/MIME, PGP/MIME, 422 etc.) used to achieve HP. 424 3.1. Interactions 426 The following use cases assume that at least the sending side 427 supports Header Protection as specified in this document. Receiving 428 sides that support this specification are expected to be able to 429 distinguish between Messages that use Header Protection as specified 430 in this document, and (legacy) Mail User Agents (MUAs) which do not 431 implement this specification. 433 [[ TODO: Verify once solution is stable and update last sentence. ]] 435 3.1.1. Main Use Case 437 Both the sending and receiving side (fully) support Header Protection 438 as specified in this document. 440 The main use case is specified in Section 4.1. 442 3.1.2. Backward Compatibility Use Cases 444 Regarding backward compatibility, the main distinction is based on 445 whether or not the receiving side conforms to MIME according to 446 [RFC2046], ff., which in particular also includes Section 2 of 447 [RFC2049] on "MIME Conformance". The following excerpt is 448 contextually relevant: 450 A mail user agent that is MIME-conformant MUST: 452 [...] 454 -- Recognize and display at least the RFC822 message 455 encapsulation (message/rfc822) in such a way as to 456 preserve any recursive structure, that is, displaying 457 or offering to display the encapsulated data in 458 accordance with its media type. 460 -- Treat any unrecognized subtypes as if they were 461 "application/octet-stream". 463 [...] 465 An MUA that meets the above conditions is said to be MIME- 466 conformant. A MIME-conformant MUA is assumed to be "safe" to 467 send virtually any kind of properly-marked data to users of 468 such mail systems, because these systems are, at a minimum, 469 capable of treating the data as undifferentiated binary, and 470 will not simply splash it onto the screen of unsuspecting 471 users. 473 [[ TODO: The compatibility of legacy HP systems with this new 474 solution, and how to handle issues surrounding future maintenance for 475 these legacy systems, will be decided by the LAMPS WG. ]] 477 3.1.2.1. Receiving Side MIME-Conformant 479 The sending side (fully) supports Header Protection as specified in 480 this document, while the receiving side does not support this 481 specification. However, the receiving side is MIME-conformant 482 according to [RFC2045], ff. (cf. Section 3.1.2). 484 This use case is specified in Section 4.2.1. 486 Note: This case should perform as expected if the sending side 487 applies this specification as outlined in Section 4.1. 489 [[ TODO: Verify once solution is stable and update last sentence. ]] 491 3.1.2.2. Receiving Side Not MIME-Conformant 493 The sending side (fully) supports Header Protection as specified in 494 this document, while the receiving side does not support this 495 specification. Furthermore, the receiving side is *not* MIME- 496 conformant according to [RFC2045], ff. (cf. Section 3.1.2). 498 This use case is specified in Section 4.2.2. 500 3.2. Protection Levels 502 3.2.1. In-Scope 504 The following Protection Levels are in scope for this document: 506 a) Signature and encryption 508 Messages containing a cryptographic signature, which are also 509 encrypted. 511 b) Signature only 513 Messages containing a cryptographic signature, but which are not 514 encrypted. 516 3.2.2. Out-of-Scope 518 Legacy implementations, implementations not (fully) compliant with 519 this document or corner-cases may lead to further Protection Levels 520 to appear on the receiving side, such as (list not exhaustive): 522 * Triple wrap 524 * Encryption only 526 * Encryption before signature 528 * Signature and encryption, but: 530 - Signature fails to validate 532 - Signature validates but the signing certificate revoked 534 * Signature only, but: 536 - with multiple valid signatures, layered atop each other 538 These Protection Levels, as well as any further Protection Levels not 539 listed in Section 3.2.1 are beyond the scope of this document. 541 4. Specification 543 This section contains the specification for Header Protection in S/ 544 MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0). 546 Note: It is likely that PGP/MIME [RFC3156] will also incorporate this 547 specification or parts of it. 549 This specification applies to the Protection Levels "signature & 550 encryption" and "signature only" (cf. Section 3.2): 552 Sending and receiving sides MUST implement the "signature and 553 encryption" Protection Level, which SHOULD be used as default on the 554 sending side. 556 Certain implementations may decide to send "signature only" Messages, 557 depending on the circumstances and customer requirements. Sending 558 sides MAY and receiving sides MUST implement "signature only" 559 Protection Level. 561 It generally is NOT RECOMMENDED to send a Message with any other 562 Protection Level. On the other hand, the receiving side must be 563 prepared to receive Messages with other Protection Levels. 565 [[ TODO: Further study is necessary to determine whether - and if yes 566 to what extent - additional guidance for handling messages with other 567 Protection Levels, e.g. "encryption only" at the receiving side 568 should be included in this document. ]] 570 4.1. Main Use Case 572 This section applies to the main use case, where the sending and 573 receiving side (fully) support Header Protection as specified herein 574 (cf. Section 3.1.1). 576 Note: The sending side specification of the main use case is also 577 applicable to the cases where the sending side (fully) supports 578 Header Protection as specified herein, while the receiving side does 579 not, but is MIME-conformant according to [RFC2045], ff. (cf. 580 Section 3.1.2 and Section 3.1.2.1). 582 Further backward compatibility cases are defined in Section 4.2. 584 4.1.1. MIME Format 586 4.1.1.1. Introduction 588 As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending 589 client MAY wrap a full MIME message in a message/RFC822 wrapper in 590 order to apply S/MIME security services to these header fields. 592 To help the receiving side to distinguish between a forwarded and a 593 wrapped message, the Content-Type header field parameter "forwarded" 594 is added as defined in [I-D.melnikov-iana-reg-forwarded]. 596 The simplified (cryptographic overhead not shown) MIME structure of 597 such an Email Message looks as follows: 599 601 603 605 607 609 The following example demonstrates how an Original Message might be 610 protected, i.e., the Original Message is contained as Inner Message 611 in the Protected Body of an Outer Message. It illustrates the first 612 Body part (of the Outer Message) as a "multipart/signed" 613 (application/pkcs7-signature) media type: 615 Lines are prepended as follows: 617 * "O: " Outer Message Header Section 619 * "I: " Message Header Section 621 * "W: " Wrapper (MIME Header Section) 622 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 623 O: Message-ID: 624 O: Subject: Meeting at my place 625 O: From: "Alexey Melnikov" 626 O: To: somebody@example.net 627 O: MIME-Version: 1.0 628 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 629 O: protocol="application/pkcs7-signature"; 630 O: boundary=boundary-AM 632 This is a multipart message in MIME format. 633 --boundary-AM 634 W: Content-Type: message/RFC822; forwarded=no 635 W: 636 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 637 I: From: "Alexey Melnikov" 638 I: Message-ID: 639 I: MIME-Version: 1.0 640 I: MMHS-Primary-Precedence: 3 641 I: Subject: Meeting at my place 642 I: To: somebody@example.net 643 I: X-Mailer: Isode Harrier Web Server 644 I: Content-Type: text/plain; charset=us-ascii 646 This is an important message that I don't want to be modified. 648 --boundary-AM 649 Content-Transfer-Encoding: base64 650 Content-Type: application/pkcs7-signature 652 [[base-64 encoded signature]] 654 --boundary-AM-- 656 The Outer Message Header Section is unprotected, while the remainder 657 (Outer Message Body) is protected. The Outer Message Body consists 658 of the wrapper (MIME Header Section) and the Inner Message (Header 659 Section and Body). 661 The wrapper is a simple MIME Header Section with media type "message/ 662 rfc822" containing a Content-Type header field parameter 663 "forwarded=no" followed by an empty line. 665 If the source is an Original (message/rfc822) Message, the Inner 666 Message Header Section is typically the same as (or a subset of) the 667 Original Message Header Section, and the Inner Message Body is 668 typically the same as the Original Message Body. 670 The Inner Message itself may contain any MIME structure. 672 Note: It is still to be decided by the LAMPS WG whether or not to 673 recommend an alternative MIME format as described in Appendix C.1.1.1 674 (instead of the currently standardized and above defined format). 676 4.1.2. Sending Side 678 This section describes the process an MUA should use to apply 679 cryptographic protection to an e-mail message with header protection. 680 We start by describing the legacy message composition process as a 681 baseline. 683 4.1.2.1. Composing a Cryptographically-Protected Message Without Header 684 Protection 686 [I-D.dkg-lamps-e2e-mail-guidance] describes the typical process for a 687 legacy crypto MUA to apply cryptographic protections to an e-mail 688 message. That guidance and terminology is replicated here for 689 reference: 691 * "origbody": the traditional unprotected message body as a well- 692 formed MIME tree (possibly just a single MIME leaf part). As a 693 well-formed MIME tree, "origbody" already has structural headers 694 ("Content-*") present. 696 * "origheaders": the intended non-structural headers for the 697 message, represented here as a list of "(h,v)" pairs, where "h" is 698 a header field name and "v" is the associated value. Note that 699 these are header fields that the MUA intends to be visible to the 700 recipient of the message. In particular, if the MUA uses the 701 "Bcc" header during composition, but plans to omit it from the 702 message (see section 3.6.3 of [RFC5322]), it will not be in 703 "origheaders". 705 * "crypto": The series of cryptographic protections to apply (for 706 example, "sign with the secret key corresponding to X.509 707 certificate X, then encrypt to X.509 certificates X and Y"). This 708 is a routine that accepts a MIME tree as input (the Cryptographic 709 Payload), wraps the input in the appropriate Cryptographic 710 Envelope, and returns the resultant MIME tree as output. 712 The algorithm returns a MIME object that is ready to be injected into 713 the mail system: 715 * Apply "crypto" to "origbody", yielding MIME tree "output" 717 * For each header name and value "(h,v)" in "origheaders": 719 - Add header "h" of "output" with value "v" 721 * Return "output" 723 4.1.2.2. Header Confidentiality Policy 725 When composing an encrypted message with protected headers, the 726 composing MUA needs a Header Confidentialiy Policy. In this 727 document, we represent that Header Confidentiality Policy as a 728 function "hcp": 730 * "hcp(name, val_in) --> val_out": this function takes a header 731 field name "name" and initial value "val_in" as arguments, and 732 returns a replacement header value "val_out". If "val_out" is the 733 special value "null", it mean that the header in question should 734 be omitted from the set of headers visible outside the 735 Cryptographic Envelope. 737 For example, an MUA that only obscures the "Subject" header field by 738 replacing it with the literal string "[...]" and does not offer 739 confidentiality to any other header fields would be represented as 740 (in pseudocode): 742 "hcp(name, val_in) --> val_out: if name is 'Subject': return '[...]' 743 else: return val_in" 745 Note that such a policy is only needed when the end-to-end 746 protections include encryption (confidentiality). No comparable 747 policy is needed for other end-to-end cryptographic protections 748 (integrity and authenticity), as they are simply uniformly applied so 749 that all header fields known by the sender have these protections. 751 This asymmetry is an unfortunate consequence of complexities in 752 message delivery systems, some of which may reject, drop, or delay 753 messages where all headers are removed from the top-level MIME 754 object. 756 This document does not mandate any particular Header Confidentiality 757 Policy, though it offers guidance for MUA implementers in selecting 758 one in Section 4.1.3. Future documents may recommend or mandate such 759 a policy for an MUA with specific needs. Such a recommendation might 760 be motivated by descriptions of metadata-derived attacks, or stem 761 from research about message deliverability, or describe new 762 signalling mechanisms, but these topics are out of scope for this 763 document. 765 4.1.2.3. Composing with "Wrapped Message" Header Protection 767 To compose a message using "Wrapped Message" header protection, we 768 use those inputs described in Section 4.1.2.1 plus the Header 769 Confidentiality Policy "hcp" defined in Section 4.1.2.2. The new 770 algorithm is: 772 * For header name and value "(h,v)" in "origheaders": 774 - Add header "h" of "origbody" with value "v" 776 * If any of the header fields in "origbody", including headers in 777 the nested internal MIME structure, contain any 8-bit UTF-8 778 characters (see section section 3.7 of [RFC6532]): 780 - Let "payload" be a new MIME part with one header: "Content- 781 Type: message/global; forwarded=no", and whose body is 782 "origbody". 784 * Else: 786 - Let "payload" be a new MIME part with one header: "Content- 787 Type: message/rfc822; forwarded=no", and whose body is 788 "origbody". 790 * Apply "crypto" to "payload", yielding MIME tree "output" 792 * If "crypto" contains encryption: 794 - Create new empty list of header field names and values "newh" 796 - For header name and value "(h,v)" in "origheaders": 798 o Let "newval" be "hcp(h, v)" 800 o If "newval" is not "null": 802 + Append "(h,newval)" to "newh" 804 - Set "origheaders" to "newh" 806 * For header name and value "(h,v)" in "origheaders": 808 - Add header "h" of "output" with value "v" 810 * Return "output" 811 Note that the Header Confidentiality Policy "hcp" is ignored if 812 "crypto" does not contain encryption. This is by design. 814 4.1.2.4. Composing with "Injected Headers" Header Protection 816 To compose a message using "Injected Headers" header protection, the 817 composing MUA needs one additional input in addition to the Header 818 Confidentiality Policy "hcp" defined in Section 4.1.2.2. 820 * "legacy": a boolean value, indicating whether any recipient of the 821 message is believed to have a legacy client. If all recipients 822 are known to implement this draft, "legacy" should be set to 823 "false". (How a MUA determines the value of "legacy" is out of 824 scope for this document; an initial implementation can simply set 825 it to "true") 827 The revised algorithm for applying cryptographic protection to a 828 message is as follows: 830 * Create a new MIME leaf part "legacydisplay" with header "Content- 831 Type: text/plain; protected-headers="v1"" and an empty body. 833 * if "crypto" contains encryption, and "legacy" is "true": 835 - For each header name and value "(h,v)" in "origheaders": 837 o If "h" is user-facing (see 838 [I-D.autocrypt-lamps-protected-headers]): 840 + If "hcp(h,v)" is not "v": 842 * Add "h: v" to the body of "legacydisplay". For 843 example, if "h" is "Subject", and "v" is "lunch 844 plans?", then add the line "Subject: lunch plans?" to 845 the body of "legacydisplay" 847 * If the body of "legacydisplay" is empty: 849 - Let "payload" be MIME part "origbody", discarding 850 "legacydisplay" 852 * Else: (body of "legacydisplay" is not empty) 854 - Construct a new MIME part "wrapper" with "Content-Type: 855 multipart/mixed" 857 - Give "wrapper" exactly two subparts: "legacydisplay" and 858 "origbody", in that order. 860 - Let "payload" be MIME part "wrapper" 862 * For each header name and value "(h,v)" in "origheaders": 864 - Add header "h" of MIME part "payload" with value "v" 866 * Set the "protected-headers" parameter on the "Content-Type" of 867 "payload" to "v1" 869 * Apply "crypto" to "payload", producing MIME tree "output" 871 * If "crypto" contains encryption: 873 - Create new empty list of header field names and values "newh" 875 - For header name and value "(h,v)" in "origheaders": 877 o Let "newval" be "hcp(h, v)" 879 o If "newval" is not "null": 881 + Add "newh[h]" to "newval" 883 - Set "origheaders" to "newh" 885 * For each header name and value "(h,v)" in "origheaders": 887 - Add header "h" of "output" with value "v" 889 * Return "output" 891 Note that both new parameters ("hcp" and "legacy") are effectively 892 ignored if "crypto" does not contain encryption. This is by design, 893 because they are irrelevant for signed-only cryptographic 894 protections. 896 4.1.2.5. Choosing Between Wrapped Message and Injected Headers 898 When composing a message with end-to-end cryptographic protections, 899 an MUA SHOULD protect the headers of that message as well as the 900 body. 902 An MUA MAY protect the headers of any outbound message using either 903 the "Wrapped Message" or the "Injected Headers" style of protection. 904 See Section 4.2 for more discussion about reasons to choose one 905 mechanism or another. 907 [[ TODO: this document should recommend generation of one particular 908 scheme by default for new implementers ]] 910 4.1.3. Default Header Confidentiality Policy 912 An MUA SHOULD have a sensible default Header Confidentiality Policy, 913 and SHOULD NOT require the user to select one. 915 The default Header Confidentiality Policy SHOULD provide 916 confidentiality for the "Subject" header field by replacing it with 917 the literal string "[...]". Most users treat the Subject of a 918 message the same way that they treat the body, and they are surprised 919 to find that the Subject of an encrypted message is visible. 921 [[ TODO: select one of the two policies below the recommended default 922 ]] 924 4.1.3.1. Minimalist Header Confidentiality Policy 926 Accordingly, the most conservative recommended Header Confidentiality 927 Policy only protects the "Subject": 929 "hcp_minimal(name, val_in) --> val_out: if name is 'Subject': return 930 '[...]' else: return val_in" 932 4.1.3.2. Strong Header Confidentiality Policy 934 Alternately, a more aggressive (and therefore more privacy- 935 preserving) Header Confidentiality Policy only leaks a handful of 936 fields whose absence is known to increase rates of delivery failure, 937 and simultaneously obscures the "Message-ID" behind a random new one: 939 "hcp_strong(name, val_in) --> val_out: if name in ['From', 'To', 940 'Cc', 'Date']: return val_in else if name is 'Subject': return 941 '[...]' else if name is 'Message-ID': return 942 generate_new_message_id() else: return null" 944 The function "generate_new_message_id()" represents whatever process 945 the MUA typically uses to generate a "Message-ID" for a new outbound 946 message. 948 4.1.3.3. Offering Stronger Header Confidentiality 950 A MUA MAY offer even stronger confidentiality for headers of an 951 encrypted message than described in Section 4.1.3.2. For example, it 952 might implement an HCP that obfuscates the "From" field, or omits the 953 "Cc" field, or ensures "Date" is represented in "UTC" (obscuring the 954 local timezone). 956 The authors of this document hope that implementers with deployment 957 experience will document their chosen Header Confidentiality Policy 958 and the rationale behind their choice. 960 4.1.4. Receiving Side 962 An MUA that receives a cryptographically-protected e-mail will render 963 it for the user. 965 The receiving MUA will render the message body, a selected subset of 966 header fields, and (as described in 967 [I-D.dkg-lamps-e2e-mail-guidance]) provide a summary of the 968 cryptographic properties of the message. 970 Most MUAs only render a subset of header fields by default. For 971 example, few MUAs typically render "Message-Id" or "Received" header 972 fields for the user, but most do render "From", "To", "Cc", "Date", 973 and "Subject". 975 A MUA that knows how to handle a message with protected headers makes 976 the following two changes to its behavior when rendering a message: 978 * If it detects that an incoming message had protected headers, it 979 renders header fields for the message from the protected headers, 980 ignoring the external (unprotected) headers. 982 * It includes information in the message's cryptographic summary to 983 indicate the types of protection that applied to each rendered 984 header field (if any). 986 A MUA that handles protected headers does _not_ need to render any 987 new header fields that it did not render before. 989 4.1.4.1. Identifying that a Message has Protected Headers 991 An incoming message can be identified as having protected headers 992 based on one of two signals: 994 * The Cryptographic Payload has "Content-Type: message/rfc822" or 995 "Content-Type: message/global" and the parameter "forwarded" has a 996 value of "no". See Section 4.1.4.3 for rendering guidance. 998 * The Cryptographic Payload has some other "Content-Type" and it has 999 parameter "protected-headers" set to "v1". See Section 4.1.4.4 1000 for rendering guidance. 1002 Messages of both types exist in the wild, and a sensible MUA should 1003 be able to handle them both. They provide the same semantics and the 1004 same meaning. 1006 4.1.4.2. Updating the Cryptographic Summary 1008 Regardless of whether a cryptographically-protected message has 1009 protected headers, the cryptographic summary of the message should be 1010 modified to indicate what protections the headers have. 1012 Each header individually has exactly one the following protections: 1014 * "unprotected" (this is the case for all headers in messages that 1015 have no protected headers) 1017 * "signed-only" (bound into the same validated signature as the 1018 enclosing message, but also visible in transit) 1020 * "encrypted-only" (only appears within the cryptographic payload; 1021 the corresponding external header was either omitted or 1022 obfuscated) 1024 * "encrypted-and-signed" (same as encrypted, but additionally is 1025 under a validatd signature) 1027 Note that while the message itself may be "encrypted-and-signed", 1028 some headers may be replicated on the outside of the message (e.g. 1029 "Date") Those headers would be "signed-only", despite the message 1030 itself being "encrypted-and-signed". 1032 Rendering this information is likely to be complex and messy --- 1033 users may not understand it. It is beyond the scope of this document 1034 to suggest any specific graphical affordances or user experience. 1035 Future work should include examples of successful rendering of this 1036 information. 1038 4.1.4.3. Rendering a Wrapped Message 1040 When the Cryptographic Payload has "Content-Type" of "message/rfc822" 1041 or "message/global", and the parameter "forwarded" is set to "no", 1042 the values of the protected headers are drawn from the headers of the 1043 Cryptographic Payload, and the body that is rendered is the body of 1044 the Cryptographic Payload. 1046 4.1.4.3.1. Example Signed-Only Wrapped Message 1048 Consider a message with this structure, where the MUA is able to 1049 validate the cryptographic signature: 1051 A └─╴application/pkcs7-mime; smime-type="signed-data" 1052 ⇩ (unwraps to) 1053 B └┬╴message/rfc822 [Cryptographic Payload] 1054 C └┬╴multipart/alternative [Rendered Body] 1055 D ├─╴text/plain 1056 E └─╴text/html 1058 The message body should be rendered the same way as this message: 1060 C └┬╴multipart/alternative 1061 D ├─╴text/plain 1062 E └─╴text/html 1064 It should render header fields taken from part "C". 1066 Its cryptographic summary should indicates that the message was 1067 signed and all rendered header fields were included in the signature. 1069 The MUA SHOULD ignore header fields from part "A" for the purposes of 1070 rendering. 1072 4.1.4.3.2. Example Encrypted-and-Signed Wrapped Message 1074 Consider a message with this structure, where the MUA is able to 1075 validate the cryptographic signature: 1077 F └─╴application/pkcs7-mime; smime-type="enveloped-data" 1078 ↧ (decrypts to) 1079 G └─╴application/pkcs7-mime; smime-type="signed-data" 1080 ⇩ (unwraps to) 1081 H └┬╴message/rfc822 [Cryptographic Payload] 1082 I └┬╴multipart/alternative [Rendered Body] 1083 J ├─╴text/plain 1084 K └─╴text/html 1086 The message body should be rendered the same way as this message: 1088 I └┬╴multipart/alternative 1089 J ├─╴text/plain 1090 K └─╴text/html 1092 It should render headers taken from part "I". 1094 Its cryptographic summary should indicates that the message was 1095 signed and encrypted. Each rendered header field found in "I" should 1096 be compared against the header field of the same name from "F". If 1097 the value found in "F" matches the value found in "I", the header 1098 field should be marked as "signed-only". If no matching header field 1099 was found in "F", or the value found did not match the value from 1100 "I", the header field should be marked as "signed-and-encrypted". 1102 4.1.4.4. Rendering a Message with Injected Headers 1104 When the Cryptographic Payload does not have a "Content-Type" of 1105 "message/rfc822" or "message/global", and the parameter "protected- 1106 headers" is set to "v1", the values of the protected headers are 1107 drawn from the headers of the Cryptographic Payload, and the body 1108 that is rendered is the Cryptographic Payload itself. 1110 4.1.4.4.1. Example Signed-only Message with Injected Headers 1112 L └─╴application/pkcs7-mime; smime-type="signed-data" 1113 ⇩ (unwraps to) 1114 M └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] 1115 N ├─╴text/plain 1116 O └─╴text/html 1118 The message body should be rendered the same way as this message: 1120 M └┬╴multipart/alternative 1121 N ├─╴text/plain 1122 O └─╴text/html 1124 It should render header fieldss taken from part "M". 1126 Its cryptographic summary should indicates that the message was 1127 signed and all rendered header fields were included in the signature. 1129 The MUA SHOULD ignore header fields from part "L" for the purposes of 1130 rendering. 1132 4.1.4.4.2. Example Signed-and-Encrypted Message with Injected Headers 1134 Consider a message with this structure, where the MUA is able to 1135 validate the cryptographic signature: 1137 P └─╴application/pkcs7-mime; smime-type="enveloped-data" 1138 ↧ (decrypts to) 1139 Q └─╴application/pkcs7-mime; smime-type="signed-data" 1140 ⇩ (unwraps to) 1141 R └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] 1142 S ├─╴text/plain 1143 T └─╴text/html 1145 The message body should be rendered the same way as this message: 1147 R └┬╴multipart/alternative 1148 S ├─╴text/plain 1149 T └─╴text/html 1151 It should render headers taken from part "R". 1153 Its cryptographic summary should indicates that the message was 1154 signed and encrypted. As in Section 4.1.4.3.2, each rendered header 1155 field found in "R" should be compared against the header field of the 1156 same name from "P". If the value found in "P" matches the value 1157 found in "R", the header field should be marked as "signed-only". If 1158 no matching header field was found in "P", or the value found did not 1159 match the value from "R", the header field should be marked as 1160 "signed-and-encrypted". 1162 4.1.4.4.3. Do Not Render Legacy Display Part 1164 As described [I-D.autocrypt-lamps-protected-headers], a message with 1165 cryptographic confidentiality protection MAY include a "Legacy 1166 Display" part for backward-compatibility with legacy MUAs 1168 The receiving MUA SHOULD avoid rendering the Legacy Display part to 1169 the user at all, since it is aware of and can render the actual 1170 Protected Headers. 1172 If a Legacy Display part is detected, it and its enclosing 1173 "multipart/mixed" wrapper should be discarded before rendering. 1175 4.1.4.4.3.1. Legacy Display Detection Algorithm 1177 A receiving MUA acting on a message SHOULD detect the presence of a 1178 Legacy Display part and the corresponding "original body" with the 1179 following simple algorithm: 1181 * Check that all of the following are true for the message: 1183 * The Cryptographic Envelope must contain an encrypting 1184 Cryptographic Layer 1186 * The Cryptographic Payload must have a "Content-Type" of 1187 "multipart/mixed" 1189 * The Cryptographic Payload must have exactly two subparts 1191 * The first subpart of the Cryptographic Payload must have a 1192 "Content-Type" of "text/plain" or "text/rfc822-headers" 1194 * The first subpart of the Cryptographic Payload's "Content-Type" 1195 must contain a property of "protected-headers", and its value must 1196 be "v1". 1198 * If all of the above are true, then the first subpart is the Legacy 1199 Display part, and the second subpart is the "original body". 1200 Otherwise, the message does not have a Legacy Display part. 1202 4.1.4.4.3.2. Legacy Display Example 1204 Consider a message with this structure, where the MUA is able to 1205 validate the cryptographic signature: 1207 U └─╴application/pkcs7-mime; smime-type="enveloped-data" 1208 ↧ (decrypts to) 1209 V └─╴application/pkcs7-mime; smime-type="signed-data" 1210 ⇩ (unwraps to) 1211 W └┬╴multipart/mixed [Cryptographic Payload] 1212 X ├─╴text/plain [Legacy Display] 1213 Y └┬╴multipart/alternative [Rendered Body] 1214 Z ├─╴text/plain 1215 A' └─╴text/html 1217 The message body should be rendered the same way as this message, 1218 effectively hiding the Legacy Display part ("X") and its wrapper: 1220 Y └┬╴multipart/alternative 1221 Z ├─╴text/plain 1222 A' └─╴text/html 1224 It should render headers taken from part "W", following the same 1225 guidance as in Section 4.1.4.4.2 and Section 4.1.4.3.2 about the 1226 cryptographic status of each rendered header field. 1228 4.1.4.5. Affordances for Debugging and Troubleshooting 1230 Note that advanced users of an MUA may need access to the original 1231 message, for example to troubleshoot problems with the MUA itself, or 1232 problems with the SMTP transport path taken by the message. 1234 A MUA that applies these rendering guidelines SHOULD ensure that the 1235 full original source of the message as it was received remains 1236 available to such a user for debugging and troubleshooting. 1238 4.1.4.6. Composing a Reply to an Encrypted Message with Protected 1239 Headers 1241 When composing a reply to an encrypted message with protected 1242 headers, the MUA is acting both as a receiving MUA and as a sending 1243 MUA. Special guidance applies here, as things can go wrong in at 1244 least two ways: leaking previously-confidential information, and 1245 replying to the wrong party. 1247 4.1.4.6.1. Avoid Leaking Encrypted Headers in Reply 1249 As noted in [I-D.dkg-lamps-e2e-mail-guidance], an MUA in this 1250 position MUST NOT leak previously-encrypted content in the clear in a 1251 followup message. The same is true for protected headers. 1253 Values from any header field that was identified as either 1254 "encrypted" or "signed-and-encrypted" based on the steps outlined 1255 above MUST NOT be placed in cleartext output when generating a 1256 message. 1258 In particular, if "Subject" was encrypted, and it is copied into the 1259 draft encrypted reply, the replying MUA MUST obfuscate the "Subject" 1260 field in the cleartext header as described above. 1262 [[ TODO: formally describe how a replying MUA should generate a 1263 message-specific Header Protection policy based on the cryptographic 1264 status of the headers of the incoming message ]] 1266 4.1.4.6.2. Avoid Misdirected Replies to Encrypted Messages with 1267 Protected Headers 1269 When replying to a message, the Composing MUA typically decides who 1270 to send the reply to based on: 1272 * the "Reply-To", "Mail-Followup-To", or "From" headers 1274 * optionally, the other "To" or "Cc" headers (if the user chose to 1275 "reply all") 1277 When a message has protected headers, the replying MUA MUST populate 1278 the destination fields of the draft message using the protected 1279 headers, and ignore any unprotected headers. 1281 This mitigates against an attack where Mallory gets a copy of an 1282 encrypted message from Alice to Bob, and then replays the message to 1283 Bob with an additional "Cc" to Mallory's own e-mail address in the 1284 message's outer header. 1286 If Bob knows Mallory's certificate already, and he replies to such a 1287 message without following the guidance in this section, it's likely 1288 that his MUA will encrypt the cleartext of the message directly to 1289 Mallory. 1291 4.1.4.7. Implicitly-rendered Header Fields 1293 While "From" and "To" and "Cc" and "Subject" and "Date" are often 1294 explicitly rendered to the user, some header fields do affect message 1295 display, without being explicitly rendered. 1297 For example, "Message-Id", "References", and "In-Reply-To" header 1298 fields may collectively be used to place a message in a "thread" or 1299 series of messages. 1301 In another example, Section 4.1.4.6.2 observes that the value of the 1302 "Reply-To" field can influence the draft reply message. So while the 1303 user may never see the "Reply-To" header directly, it is implicitly 1304 "rendered" when the user interacts with the message by replying to 1305 it. 1307 An MUA that depends on any implicitly-rendered header field in a 1308 message with protected headers SHOULD use the value from the 1309 protected header, and SHOULD NOT use any value found outside the 1310 cryptographic protection. 1312 4.1.4.8. Unprotected Headers Added in Transit 1314 Some headers are legitimately added in transit, and could not have 1315 been known to the sender at message composition time. 1317 The most common of these headers are "Received" and "DKIM-Signature", 1318 neither of which are typically rendered, either explicitly or 1319 implicitly. 1321 If a receiving MUA has specific knowledge about a given header field, 1322 including that: 1324 * the header field would not have been known to the original sender, 1325 and 1327 * the header field might be rendered explicitly or implicitly, 1328 then the MUA MAY decide to operate on the value of that header field 1329 from the unprotected header section, even though the message has 1330 protected headers. 1332 The MUA MAY prefer to verify that the headers in question have 1333 additional transit-derived cryptographic protections (e.g., to test 1334 whether they are covered by a valid "DKIM-Signature") before 1335 rendering or acting on them. 1337 Specific examples appear below. 1339 4.1.4.8.1. Mailing list headers: List-* and Archived-At 1341 If the message arrives through a mailing list, the list manager 1342 itself may inject headers (most of which start with "List-") in the 1343 message: 1345 * "List-Archive" 1347 * "List-Subscribe" 1349 * "List-Unsubscribe" 1351 * "List-Id" 1353 * "List-Help" 1355 * "List-Post" 1357 * "Archived-At" 1359 For some MUAs, these headers are implicitly rendered, by providing 1360 buttons for actions like "Subscribe", "View Archived Version", "Reply 1361 List", "List Info", etc. 1363 An MUA that receives a message with protected headers that contains 1364 these header fields in the unprotected section, and that has reason 1365 to believe the message is coming through a mailing list MAY decide to 1366 render them to the user (explicitly or implicitly) even though they 1367 are not protected. 1369 FIXME: other examples of unprotected transit headers? 1371 4.2. Backward Compatibility Use Cases 1372 4.2.1. Receiving Side MIME-Conformant 1374 This section applies to the case where the sending side (fully) 1375 supports Header Protection as specified in this document, while the 1376 receiving side does not support this specification, but is MIME- 1377 conformant according to [RFC2045], ff. (cf. Section 3.1.2 and 1378 Section 3.1.2.1) 1380 The sending side specification of the main use case (cf. 1381 Section 4.1) MUST ensure that receiving sides can still recognize and 1382 display or offer to display the encapsulated data in accordance with 1383 its media type (cf. [RFC2049], Section 2). In particular, receiving 1384 sides that do not support this specification, but are MIME-conformant 1385 according to [RFC2045], ff. can still recognize and display the 1386 Message intended for the user. 1388 [[ TODO: Verify once solution is stable and update last sentence. ]] 1390 4.2.2. Receiving Side Not MIME-Conformant 1392 This section applies to cases where the sending side (fully) supports 1393 Header Protection as specified in this document, while the receiving 1394 side neither supports this specification *nor* is MIME-conformant 1395 according to [RFC2045], ff. (cf. Section 3.1.2 and Section 3.1.2.2). 1397 [I-D.autocrypt-lamps-protected-headers] describes a possible way to 1398 achieve backward compatibility with existing S/MIME (and PGP/MIME) 1399 implementations that predate this specification and are not MIME- 1400 conformant (Legacy Display) either. It mainly focuses on email 1401 clients that do not render emails which utilize header protection in 1402 a user friendly manner, which may confuse the user. While this has 1403 been observed occasionally in PGP/MIME (cf. [RFC3156]), the extent 1404 of this problem with S/MIME implementations is still unclear. (Note: 1405 At this time, none of the samples in 1406 [I-D.autocrypt-lamps-protected-headers] apply header protection as 1407 specified in Section 3.1 of [RFC8551], which is wrapping as Media 1408 Type "message/RFC822".) 1410 Should serious backward compatibility issues with rendering at the 1411 receiving side be discovered, the Legacy Display format described in 1412 [I-D.autocrypt-lamps-protected-headers] may serve as a basis to 1413 mitigate those issues (cf. Section 4.2). 1415 Another variant of backward compatibility has been implemented by pEp 1416 [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has 1417 implemented this for PGP/MIME, but not yet S/MIME. 1419 5. Usability Considerations 1421 This section describes concerns for MUAs that are interested in easy 1422 adoption of header protection by normal users. 1424 While they are not protocol-level artifacts, these concerns motivate 1425 the protocol features described in this document. 1427 See also the Usability section in [I-D.dkg-lamps-e2e-mail-guidance]. 1429 5.1. Mixed Protections Within a Message Are Hard To Understand 1431 [[ TODO ]] 1433 5.2. Users Should Not Have To Choose a Header Confidentiality Policy 1435 [[ TODO ]] 1437 6. Security Considerations 1439 [[ TODO ]] 1441 7. Privacy Considerations 1443 [[ TODO ]] 1445 8. IANA Considerations 1447 This document requests no action from IANA. 1449 [[ RFC Editor: This section may be removed before publication. ]] 1451 9. Acknowledgments 1453 The authors would like to thank the following people who have 1454 provided helpful comments and suggestions for this document: Berna 1455 Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista 1456 Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ 1457 Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. 1459 10. References 1461 10.1. Normative References 1463 [I-D.dkg-lamps-e2e-mail-guidance] 1464 Gillmor, D. K., "Guidance on End-to-End E-mail Security", 1465 Work in Progress, Internet-Draft, draft-dkg-lamps-e2e- 1466 mail-guidance-01, 22 February 2021, 1467 . 1470 [I-D.ietf-lamps-header-protection-requirements] 1471 Melnikov, A. and B. Hoeneisen, "Problem Statement and 1472 Requirements for Header Protection", Work in Progress, 1473 Internet-Draft, draft-ietf-lamps-header-protection- 1474 requirements-01, 29 October 2019, 1475 . 1478 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1479 Extensions (MIME) Part One: Format of Internet Message 1480 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1481 . 1483 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1484 Extensions (MIME) Part Two: Media Types", RFC 2046, 1485 DOI 10.17487/RFC2046, November 1996, 1486 . 1488 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1489 Extensions (MIME) Part Five: Conformance Criteria and 1490 Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, 1491 . 1493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1494 Requirement Levels", BCP 14, RFC 2119, 1495 DOI 10.17487/RFC2119, March 1997, 1496 . 1498 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1499 DOI 10.17487/RFC5322, October 2008, 1500 . 1502 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1503 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1504 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1505 April 2019, . 1507 10.2. Informative References 1509 [I-D.autocrypt-lamps-protected-headers] 1510 Einarsson, B. R., juga, and D. K. Gillmor, "Protected 1511 Headers for Cryptographic E-mail", Work in Progress, 1512 Internet-Draft, draft-autocrypt-lamps-protected-headers- 1513 02, 20 December 2019, . 1516 [I-D.dkg-lamps-samples] 1517 Gillmor, D. K., "S/MIME Example Keys and Certificates", 1518 Work in Progress, Internet-Draft, draft-dkg-lamps-samples- 1519 05, 18 February 2021, . 1522 [I-D.melnikov-iana-reg-forwarded] 1523 Melnikov, A. and B. Hoeneisen, "IANA Registration of 1524 Content-Type Header Field Parameter 'forwarded'", Work in 1525 Progress, Internet-Draft, draft-melnikov-iana-reg- 1526 forwarded-00, 4 November 2019, 1527 . 1530 [I-D.pep-email] 1531 Marques, H., "pretty Easy privacy (pEp): Email Formats and 1532 Protocols", Work in Progress, Internet-Draft, draft-pep- 1533 email-01, 2 November 2020, 1534 . 1536 [pEp.mixnet] 1537 pEp Foundation, "Mixnet", June 2020, 1538 . 1540 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1541 "MIME Security with OpenPGP", RFC 3156, 1542 DOI 10.17487/RFC3156, August 2001, 1543 . 1545 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1546 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1547 . 1549 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1550 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1551 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1552 . 1554 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1555 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 1556 . 1558 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 1559 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 1560 2012, . 1562 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1563 Message Authentication, Reporting, and Conformance 1564 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1565 . 1567 Appendix A. Test Vectors 1569 This section contains sample messages using the different schemes 1570 described in this document. Each sample contains a MIME object, and 1571 examples of how an MUA might render it. 1573 The cryptographic protections used in this document use the S/MIME 1574 standard, and keying material and certificates come from 1575 [I-D.dkg-lamps-samples]. 1577 For the signed-and-encrypted messages, only the "Subject" header is 1578 obscured. 1580 A.1. Wrapped Message examples 1582 The examples in this subsection use the "Wrapped Message" header 1583 protection scheme. 1585 A.1.1. Wrapped Message: signed-only, with PKCS7 signedData 1587 [[ TODO ]] 1589 A.1.2. Wrapped Message: signed-only, using multipart/signed 1591 [[ TODO ]] 1593 A.1.3. Wrapped Message: signed-and-encrypted 1595 [[ TODO ]] 1597 A.2. Injected Headers examples 1599 The examples in this subsection use the "Injected Headers" header 1600 protection scheme. 1602 A.2.1. Injected Headers: signed-only, with PKCS7 signedData 1604 [[ TODO ]] 1606 A.2.2. Injected Headers: signed-only, using multipart/signed 1608 [[ TODO ]] 1610 A.2.3. Injected Headers: signed-and-encrypted with Legacy Display part 1612 [[ TODO ]] 1614 A.2.4. Injected Headers: signed-and-encrypted without Legacy Display 1615 part 1617 [[ TODO ]] 1619 A.3. Messages without Header Protection 1621 The examples in this subsection have cryptographic protection, but no 1622 header protection. They are provided in this document as a 1623 counterexample. An MUA implementer can use these messages to verify 1624 that the reported cryptographic summary of the message indicates no 1625 header protection. 1627 A.3.1. Unprotected Headers: signed-only, with PKCS7 signedData 1629 [[ TODO ]] 1631 A.3.2. Unprotected Headers: signed-only, using multipart/signed 1633 [[ TODO ]] 1635 A.3.3. Unprotected Headers: signed-and-encrypted 1637 [[ TODO ]] 1639 Appendix B. Additional information 1641 B.1. Stored Variants of Messages with Bcc 1643 Messages containing at least one recipient address in the Bcc header 1644 field may appear in up to three different variants: 1646 1. The Message for the recipient addresses listed in To or Cc header 1647 fields, which must not include the Bcc header field neither for 1648 signature calculation nor for encryption. 1650 2. The Message(s) sent to the recipient addresses in the Bcc header 1651 field, which depends on the implementation: 1653 a) One Message for each recipient in the Bcc header field 1654 separately, with a Bcc header field containing only the address 1655 of the recipient it is sent to. 1657 b) The same Message for each recipient in the Bcc header field 1658 with a Bcc header field containing an indication such as 1659 "Undisclosed recipients", but no addresses. 1661 c) The same Message for each recipient in the Bcc header field 1662 which does not include a Bcc header field (this Message is 1663 identical to 1. / cf. above). 1665 3. The Message stored in the 'Sent'-Folder of the sender, which 1666 usually contains the Bcc unchanged from the original Message, 1667 i.e., with all recipient addresses. 1669 The most privacy preserving method of the alternatives (2a, 2b, and 1670 2c) is to standardize 2a, as in the other cases (2b and 2c), 1671 information about hidden recipients is revealed via keys. In any 1672 case, the Message has to be cloned and adjusted depending on the 1673 recipient. 1675 Appendix C. Text Moved from Above 1677 Note: Per an explicit request by the chair of the LAMPS WG to only 1678 present one option for the specification, the following text has been 1679 stripped from the main body of the draft. It is preserved in an 1680 Appendix for the time being and may be moved back to the main body or 1681 deleted, depending on the decision of the LAMPS WG. 1683 C.1. MIME Format 1685 Currently there are two options in discussion: 1687 1. The option according to the current S/MIME specification (cf. 1688 [RFC8551]) 1690 2. An alternative option that is based on the former "memory hole" 1691 approach (cf. [I-D.autocrypt-lamps-protected-headers]) 1693 C.1.1. S/MIME Specification 1695 Note: This is currently described in the main part of this document. 1697 C.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory 1698 Hole") 1700 An alternative option (based on the former autocrypt "Memory Hole" 1701 approach) to be considered, is described in 1702 [I-D.autocrypt-lamps-protected-headers]. 1704 Unlike the option described in Appendix C.1.1, this option does not 1705 use a "message/RFC822" wrapper to unambiguously delimit the Inner 1706 Message. 1708 Before choosing this option, the following two issues must be 1709 assessed to ensure no interoperability issues result from it: 1711 1. How current MIME parser implementations treat non-MIME Header 1712 Fields, which are not part of the outermost MIME entity and not 1713 part of a Message wrapped into a MIME entity of media type 1714 "message/rfc822", and how such Messages are rendered to the user. 1716 [I-D.autocrypt-lamps-protected-headers] provides some examples 1717 for testing this. 1719 2. MIME-conformance, i.e. whether or not this option is (fully) 1720 MIME-conformant [RFC2045] ff., in particular also Section 5.1. of 1721 [RFC2046] on "Multipart Media Type). In the following an excerpt 1722 of paragraphs that may be relevant in this context: 1724 The only header fields that have defined meaning for body parts 1725 are those the names of which begin with "Content-". All other 1726 header fields may be ignored in body parts. Although they 1727 should generally be retained if at all possible, they may be 1728 discarded by gateways if necessary. Such other fields are 1729 permitted to appear in body parts but must not be depended on. 1730 "X-" fields may be created for experimental or private 1731 purposes, with the recognition that the information they 1732 contain may be lost at some gateways. 1734 NOTE: The distinction between an RFC 822 Message and a body 1735 part is subtle, but important. A gateway between Internet and 1736 X.400 mail, for example, must be able to tell the difference 1737 between a body part that contains an image and a body part 1738 that contains an encapsulated Message, the body of which is a 1739 JPEG image. In order to represent the latter, the body part 1740 must have "Content-Type: message/rfc822", and its body (after 1741 the blank line) must be the encapsulated Message, with its own 1742 "Content-Type: image/jpeg" header field. The use of similar 1743 syntax facilitates the conversion of Messages to body parts, 1744 and vice versa, but the distinction between the two must be 1745 understood by implementors. (For the special case in which 1746 parts actually are Messages, a "digest" subtype is also 1747 defined.) 1749 The MIME structure of an Email Message looks as follows: 1751 1753 1755 1757 1759 The following example demonstrates how an Original Message might be 1760 protected, i.e., the Original Message is contained as Inner Message 1761 in the Protected Body of an Outer Message. It illustrates the first 1762 Body part (of the Outer Message) as a "multipart/signed" 1763 (application/pkcs7-signature) media type: 1765 Lines are prepended as follows: 1767 * "O: " Outer Message Header Section 1769 * "I: " Message Header Section 1770 O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 1771 O: Message-ID: 1772 O: Subject: Meeting at my place 1773 O: From: "Alexey Melnikov" 1774 O: MIME-Version: 1.0 1775 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 1776 O: protocol="application/pkcs7-signature"; 1777 O: boundary=boundary-AM 1779 This is a multipart message in MIME format. 1780 --boundary-AM 1781 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 1782 I: From: "Alexey Melnikov" 1783 I: Message-ID: 1784 I: MIME-Version: 1.0 1785 I: MMHS-Primary-Precedence: 3 1786 I: Subject: Meeting at my place 1787 I: To: somebody@example.net 1788 I: X-Mailer: Isode Harrier Web Server 1789 I: Content-Type: text/plain; charset=us-ascii 1791 This is an important message that I don't want to be modified. 1793 --boundary-AM 1794 Content-Transfer-Encoding: base64 1795 Content-Type: application/pkcs7-signature 1797 [[base-64 encoded signature]] 1799 --boundary-AM-- 1801 The Outer Message Header Section is unprotected, while the remainder 1802 (Outer Message Body) is protected. The Outer Message Body consists 1803 of the Inner Message (Header Section and Body). 1805 The Inner Message Header Section is the same as (or a subset of) the 1806 Original Message Header Section. 1808 The Inner Message Body is the same as the Original Message Body. 1810 The Original Message itself may contain any MIME structure. 1812 C.1.2. Sending Side 1814 To ease explanation, the following describes the case where an 1815 Original (message/rfc822) Message to be protected is present. If 1816 this is not the case, Original Message means the (virtual) Message 1817 that would be constructed for sending it as unprotected email. 1819 C.1.2.1. Inner Message Header Fields 1821 It is RECOMMENDED that the Inner Message contains all Header Fields 1822 of the Original Message with the exception of the following Header 1823 Field, which MUST NOT be included within the Inner Message nor within 1824 any other protected part of the Message: 1826 * Bcc 1828 [[ TODO: Bcc handling needs to be further specified (see also 1829 Appendix B.1). Certain MUAs cannot properly decrypt Messages with 1830 Bcc recipients. ]] 1832 C.1.2.2. Wrapper 1834 The wrapper is a simple MIME Header Section followed by an empty line 1835 preceding the Inner Message (inside the Outer Message Body). The 1836 media type of the wrapper MUST be "message/RFC822" and MUST contain 1837 the Content-Type header field parameter "forwarded=no" as defined in 1838 [I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously 1839 delimits the Inner Message from the rest of the Message. 1841 C.1.2.3. Cryptographic Layers / Envelope 1843 [[ TODO: Basically refer to S/MIME standards ]] 1845 C.1.2.4. Sending Side Message Processing 1847 For a protected Message the following steps are applied before a 1848 Message is handed over to the Submission Entity: 1850 C.1.2.4.1. Step 1: Decide on Protection Level and Information 1851 Disclosure 1853 The implementation which applies protection to a Message must decide: 1855 * Which Protection Level (signature and/or encryption) shall be 1856 applied to the Message? This depends on user request and/or local 1857 policy as well as availability of cryptographic keys. 1859 * Which Header Fields of the Original Message shall be part of the 1860 Outer Message Header Section? This typically depends on local 1861 policy. By default, the Essential Header Fields are part of the 1862 Outer Message Header Section; cf. Appendix C.1.2.5. 1864 * Which of these Header Fields are to be obfuscated? This depends 1865 on local policy and/or specific Privacy requirements of the user. 1866 By default only the Subject Header Field is obfuscated; cf. 1867 Appendix C.1.2.5. 1869 C.1.2.4.2. Step 2: Compose the Outer Message Header Section 1871 Depending on the decision in Appendix C.1.2.4.1, the implementation 1872 shall compose the Outer Message Header Section. (Note that this also 1873 includes the necessary MIME Header Section part for the following 1874 protection layer.) 1876 Outer Header Fields that are not obfuscated should contain the same 1877 values as in the Original Message (except for MIME Header 1878 Section part, which depends on the Protection Level selected in 1879 Appendix C.1.2.4.1). 1881 C.1.2.4.3. Step 3: Apply Protection to the Original Message 1883 Depending on the Protection Level selected in Appendix C.1.2.4.1, the 1884 implementation applies signature and/or encryption to the Original 1885 Message, including the wrapper (as per [RFC8551]), and sets the 1886 resulting package as the Outer Message Body. 1888 The resulting (Outer) Message is then typically handed over to the 1889 Submission Entity. 1891 [[ TODO: Example ]] 1893 C.1.2.5. Outer Message Header Fields 1895 C.1.2.5.1. Encrypted Messages 1897 To maximize Privacy, it is strongly RECOMMENDED to follow the 1898 principle of Data Minimization (cf. Section 2.1). 1900 However, the Outer Message Header Section SHOULD contain the 1901 Essential Header Fields and, in addition, MUST contain the Header 1902 Fields of the MIME Header Section part to describe Cryptographic 1903 Layer of the protected MIME subtree as per [RFC8551]. 1905 The following Header Fields are defined as the Essential Header 1906 Fields: 1908 * From 1910 * To (if present in the Original Message) 1911 * Cc (if present in the Original Message) 1913 * Bcc (if present in the Original Message, see also Appendix B.1) 1915 * Date 1917 * Message-ID 1919 * Subject 1921 Further processing by the Submission Entity normally depends on part 1922 of these Header Fields, e.g. From and Date HFs are required by 1923 [RFC5322]. Furthermore, not including certain Header Fields may 1924 trigger spam detection to flag the Message, and/or lead to user 1925 experience (UX) issues. 1927 For further Data Minimization, the value of the Subject Header Field 1928 SHOULD be obfuscated as follows: 1930 * Subject: [...] 1932 and it is RECOMMENDED to replace the Message-ID by a new randomly 1933 generated Message-ID. 1935 In addition, the value of other Essential Header Fields MAY be 1936 obfuscated. 1938 Non-Essential Header Fields SHOULD be omitted from the Outer Message 1939 Header Section where possible. If Non-essential Header Fields are 1940 included in the Outer Message Header Section, those MAY be obfuscated 1941 too. 1943 Header Fields that are not obfuscated should contain the same values 1944 as in the Original Message. 1946 If an implementation obfuscates the From, To, and/or Cc Header 1947 Fields, it may need to provide access to the clear text content of 1948 these Header Fields to the Submission Entity for processing purposes. 1949 This is particularly relevant, if proprietary Submission Entities are 1950 used. Obfuscation of Header Fields may adversely impact spam 1951 filtering. 1953 (A use case for obfuscation of all Outer Message Header Fields is 1954 routing email through the use of onion routing or mix networks, e.g. 1955 [pEp.mixnet].) 1956 The MIME Header Section part is the collection of MIME Header Fields 1957 describing the following MIME structure as defined in [RFC2045]. A 1958 MIME Header Section part typically includes the following Header 1959 Fields: 1961 * Content-Type 1963 * Content-Transfer-Encoding 1965 * Content-Disposition 1967 The following example shows the MIME Header Section part of an S/MIME 1968 signed Message (using application/pkcs7-mime with SignedData): 1970 MIME-Version: 1.0 1971 Content-Type: application/pkcs7-mime; smime-type=signed-data; 1972 name=smime.p7m 1973 Content-Transfer-Encoding: base64 1974 Content-Disposition: attachment; filename=smime.p7m 1976 Depending on the scenario, further Header Fields MAY be exposed in 1977 the Outer Message Header Section, which is NOT RECOMMENDED unless 1978 justified. Such Header Fields may include e.g.: 1980 * References 1982 * Reply-To 1984 * In-Reply-To 1986 C.1.2.5.2. Unencrypted Messages 1988 The Outer Message Header Section of unencrypted Messages SHOULD 1989 contain at least the Essential Header Fields and, in addition, MUST 1990 contain the Header Fields of the MIME Header Section part to describe 1991 Cryptographic Layer of the protected MIME subtree as per [RFC8551]. 1992 It may contain further Header Fields, in particular those also 1993 present in the Inner Message Header Section. 1995 Appendix D. Document Considerations 1997 [[ RFC Editor: This section is to be removed before publication ]] 1999 This draft is built from markdown source, and its development is 2000 tracked in a git repository (https://gitlab.com/dkg/lamps-header- 2001 protection). 2003 While minor editorial suggestions and nit-picks can be made as merge 2004 requests (https://gitlab.com/dkg/lamps-header-protection), please 2005 direct all substantive discussion to the LAMPS mailing list 2006 (https://www.ietf.org/mailman/listinfo/spasm) at "spasm@ietf.org". 2008 Appendix E. Document Changelog 2010 [[ RFC Editor: This section is to be removed before publication ]] 2012 * draft-ietf-lamps-header-protection-03 2014 - dkg takes over from Bernie as primary author 2016 - Add Usability section 2018 - describe two distinct formats "Wrapped Message" and "Injected 2019 Headers" 2021 - Introduce Header Confidentiality Policy model 2023 - Overhaul message composition guidance 2025 - Simplify document creation workflow, move public face to gitlab 2027 * draft-ietf-lamps-header-protection-02 2029 - editorial changes / improve language 2031 * draft-ietf-lamps-header-protection-01 2033 - Add DKG as co-author 2035 - Partial Rewrite of Abstract and Introduction [HB/AM/DKG] 2037 - Adding definiations for Cryptographic Layer, Cryptographic 2038 Payload, and Cryptographic Envelope (reference to 2039 [I-D.dkg-lamps-e2e-mail-guidance]) [DKG] 2041 - Enhanced MITM Definition to include Machine- / Meddler-in-the- 2042 middle [HB] 2044 - Relaxed definition of Original message, which may not be of 2045 type "message/rfc822" [HB] 2047 - Move "memory hole" option to the Appendix (on request by Chair 2048 to only maintain one option in the specification) [HB] 2050 - Updated Scope of Protection Levels according to WG discussion 2051 during IETF-108 [HB] 2053 - Obfuscation recommendation only for Subject and Message-Id and 2054 distinguish between Encrypted and Unencrypted Messages [HB] 2056 - Removed (commented out) Header Field Flow Figure (it appeared 2057 to be confusing as is was) [HB] 2059 * draft-ietf-lamps-header-protection-00 2061 - Initial version (text partially taken over from 2062 [I-D.ietf-lamps-header-protection-requirements] 2064 Appendix F. Open Issues 2066 [[ RFC Editor: This section should be empty and is to be removed 2067 before publication. ]] 2069 * Ensure "protected header" (Ex-Memory-Hole) option is (fully) 2070 compliant with the MIME standard, in particular also [RFC2046], 2071 Section 5.1. (Multipart Media Type) Appendix C.1.1.1. 2073 * Test Vectors! This should be a new appendix section, to avoid 2074 injecting large blobs of unreadable data in the main text. Once 2075 present, we can point to the relevant test vector in the main text 2076 by reference. 2078 * Should Outer Message Header Section (as received) be preserved for 2079 the user? (Section 4.1.4.5) 2081 * Decide on whether or not merge requirements from 2082 [I-D.ietf-lamps-header-protection-requirements] into this 2083 document. 2085 * Decide what parts of [I-D.autocrypt-lamps-protected-headers] to 2086 merge into this document. 2088 * Enhance Introduction Section 1 and Problem Statement (Section 2). 2090 * Decide on whether or not specification for more legacy HP 2091 requirements should be added to this document (Section 3.1.2). 2093 * Verify simple backward compatibility case (Receiving Side MIME- 2094 Conformant) is working; once solution is stable and update 2095 paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1 2096 accordingly. 2098 * Verify ability to distinguish between Messages with Header 2099 Protection as specified in this document and legacy clients and 2100 update Section 3.1 accordingly. 2102 * Improve definitions of Protection Levels and enhance list of 2103 Protection Levels (Section 3.2, Section 4). 2105 * Privacy Considerations Section 7 2107 * Security Considerations Section 6 2109 Authors' Addresses 2111 Daniel Kahn Gillmor 2112 American Civil Liberties Union 2113 125 Broad St. 2114 New York, NY, 10004 2115 United States of America 2117 Email: dkg@fifthhorseman.net 2119 Bernie Hoeneisen 2120 pEp Foundation 2121 Oberer Graben 4 2122 CH- CH-8400 Winterthur 2123 Switzerland 2125 Email: bernie.hoeneisen@pep.foundation 2126 URI: https://pep.foundation/ 2128 Alexey Melnikov 2129 Isode Ltd 2130 14 Castle Mews 2131 Hampton, Middlesex 2132 TW12 2NP 2133 United Kingdom 2135 Email: alexey.melnikov@isode.com