idnits 2.17.1 draft-luck-lamps-pep-header-protection-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2019) is 1870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-birk-pep-03 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Luck 3 Internet-Draft pEp Foundation 4 Intended status: Informational B. Hoeneisen 5 Expires: September 13, 2019 Ucom.ch 6 March 12, 2019 8 pretty Easy privacy (pEp): Header Protection 9 draft-luck-lamps-pep-header-protection-01 11 Abstract 13 Issues with email header protection in S/MIME have been recently 14 raised in the IETF LAMPS Working Group. The need for amendments to 15 the existing specification regarding header protection was expressed. 17 The pretty Easy privacy (pEp) implementations currently use a 18 mechanism quite similar to the currently standardized message 19 wrapping for S/MIME. The main difference is that pEp is using PGP/ 20 MIME instead, and adds space for carrying public keys next to the 21 protected message. 23 In LAMPS voices have also been expressed, that whatever mechanism 24 will be chosen, it should not be limited to S/MIME, but also 25 applicable to PGP/MIME. 27 This document aims to contribute to this discussion and share pEp 28 implementation experience with email header protection. 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 September 13, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4 67 2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5 68 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 73 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 74 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8 75 4.2. Additional Requirements for Backward-Compatibility With 76 Legacy Clients Unaware of Header Protection . . . . . . . 8 77 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 78 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8 79 4.3. Additional Requirements for Backward-Compatibility with 80 Legacy Header Protection Systems (if supported) . . . . . 8 81 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9 82 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9 83 5. Message Format for progressive header disclosure . . . . . . 9 84 5.1. Design principles . . . . . . . . . . . . . . . . . . . . 9 85 5.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 86 5.3. Inner message . . . . . . . . . . . . . . . . . . . . . . 11 87 5.4. Content-Type property "forwarded" . . . . . . . . . . . . 11 88 5.5. Outer message . . . . . . . . . . . . . . . . . . . . . . 12 89 5.6. Transport message . . . . . . . . . . . . . . . . . . . . 14 90 5.7. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 15 91 6. Candidate Header Fields for Header Protection . . . . . . . . 15 92 7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 15 93 8. Processing Incoming Email under Progressive Header Disclosure 16 94 8.1. Resolving Conflicting Protected and Unprotected Header 95 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 8.2. Processing of Signed-only Email . . . . . . . . . . . . . 16 97 8.3. Incoming Filter Processing . . . . . . . . . . . . . . . 16 98 8.3.1. Staged Filtering of Inbound Messages . . . . . . . . 17 99 8.4. Outgoing Filter Processing . . . . . . . . . . . . . . . 17 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 101 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 102 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18 103 10.2. Current software implementing pEp . . . . . . . . . . . 18 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 107 12.2. Informative References . . . . . . . . . . . . . . . . . 20 108 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 21 109 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 21 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 112 1. Introduction 114 A range of protocols for the protection of electronic mail (email) 115 exist, which allow to assess the authenticity and integrity of the 116 email headers section or selected header fields from the domain-level 117 perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376] 118 and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message 119 Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These 120 protocols, while essential to responding to a range of attacks on 121 email, do not offer full end-to-end protection to the headers section 122 and are not capable of providing privacy for the information 123 contained therein. 125 The need for means of Data Minimization, which includes data 126 spareness and hiding of all information, which technically can be 127 hidden, has grown in importance over the past years. 129 A standard for end-to-end protection of the email headers section 130 exists for S/MIME since version 3.1. (cf. [RFC5751] and 131 [I-D.ietf-lamps-rfc5751-bis]): 133 In order to protect outer, non-content-related message header 134 fields (for instance, the "Subject", "To", "From", and "Cc" 135 fields), the sending client MAY wrap a full MIME message in a 136 message/rfc822 wrapper in order to apply S/MIME security services 137 to these header fields. 139 No mechanism for header protection has been standardized for PGP 140 (Pretty Good Privacy) yet. 142 End-to-end protection for the email headers section is currently not 143 widely implemented - neither for messages protected by means of 144 S/MIME nor PGP. At least two variants of header protection are known 145 to be implemented. A recently submitted Internet-Draft 146 [I-D.melnikov-lamps-header-protection] discusses the two variants and 147 the challenges with header protection for S/MIME. The two variants 148 are referred to as: 150 o Option 1: Memory Hole 152 o Option 2: Wrapping with message/rfc822 or message/global 154 pEp (pretty Easy privacy) [I-D.birk-pep] for email 155 [I-D.marques-pep-email] already implements an option quite similar to 156 Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 5, 157 ff.). Existing implementations of pEp have also added inbound 158 support for "Memory Hole" referred to above as Option 1, thus being 159 able to study the differences and the implementator's challenges. 161 Interoperability and implementation symmetry between PGP/MIME and 162 S/MIME is planned by pEp, but still in an early stage of development. 164 This document lists generic use cases (Section 3) and requirements 165 for header protection (Section 4) and describes progressive header 166 disclosure as implemented in the "pEp message format version 2". 167 This format inherently offers header protection, and may be 168 implemented independently by mail user agents otherwise not 169 conforming to pEp standards (Section 5, ff.). 171 2. Terms 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 o Man-in-the-middle attack (MITM): cf. [RFC4949] 179 2.1. The OpenPGP Radix-64 181 In the examples following in this section, it is a common pattern to 182 have a MIME encoded mail containing ("wrapping") another signed and 183 eventually encrypted mail. Such enclosed mails are encoded following 184 the OpenPGP standard, which specifies an encoding called "Radix-64", 185 which is 7-bit transport-encoding compatible by design. 187 The Radix-64 consists of a begin and an end Armor Header Line, a 188 stream of base64-encoded data limited to 78 characters per line plus 189 , and an encoded CRC-24 value. 191 The following is an example, with some similar lines of base64 output 192 replaced with ellipsis: 194 -----BEGIN PGP MESSAGE----- 195 hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv 196 ... 197 j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt 198 Xd9bdvHx/ReenAk/ 199 =7WaL 200 -----END PGP MESSAGE----- 202 To make the examples look more compact and relevant, the above will 203 be replaced symbolically by: 205 [[----- OpenPGP Radix-64 Block -----]] 207 2.1.1. Radix-64 in the Context of MIME Messages 209 Note that OpenPGP and MIME specifications overlap when a Radix-64 210 immediately precedes a MIME boundary. The sequence 211 immediately preceding a MIME boundary delimiter line is considered to 212 be part of the delimiter in [RFC2046], 5.1. And in OpenPGP, line 213 endings are considered a part of the Armor Header Line for the 214 purposes of determining the content they delimit in [RFC4880], 6.2. 215 Keeping an empty line between the end Armor Header Line and the MIME 216 boundary line is suggested. 218 3. Use Cases 220 In the following, we show the generic use cases that need to be 221 addressed independently of whether S/MIME, PGP/MIME or any other 222 technology is used for which Header Protection (HP) is to be applied 223 to. 225 3.1. Interactions 227 The main interaction case for Header Protection (HP) is: 229 1) Both peers (sending and receiving side) fully support HP 231 For backward compatibility of legacy clients - unaware of any HP - 232 the following intermediate interactions need to be considered as 233 well: 235 2) The sending side fully supports HP, while the receiving side does 236 not support any HP 238 3) The sending side does not support any HP, while the receiving 239 side fully supports HP (trivial case) 241 4) Neither the sending side nor the receiving side supports any HP 242 (trivial case) 244 The following intermediate use cases may need to be considered as 245 well for backward compatibility with legacy HP systems, such as 246 S/MIME since version 3.1 (cf. [RFC5751] and 247 [I-D.ietf-lamps-rfc5751-bis]), in the following designated as legacy 248 HP: 250 5) The sending side fully supports HP, while the receiving side 251 supports legacy HP only 253 6) The sending side supports legacy HP only, while the receiving side 254 fully supports HP 256 7) Both peers (sending and receiving side) support legacy HP only 258 8) The sending side supports legacy HP only, while the receiving side 259 does not support any HP 261 9) The sending side does not support any HP, while the receiving side 262 supports legacy HP only (trivial case) 264 Note: It is to be decided whether to ensure legacy HP systems do not 265 conflict with any new solution for HP at all or whether (and to which 266 degree) backward compatibility to legacy HP systems shall be 267 maintained. 269 3.2. Protection Levels 271 The following protection levels need to be considered: 273 a) signature and encryption 275 b) signature only 277 c) encryption only [[ TODO: verify whether relevant ]] 279 4. Requirements 281 In the following a list of requirements that need to be addressed 282 independently of whether S/MIME, PGP/MIME or any other technology is 283 used to apply HP to. 285 4.1. General Requirements 287 This subsection is listing the requirements to address use case 1) 288 (cf. Section 3.1). 290 G1: Define the format for HP for all protection levels. This includes 291 MIME structure, Content-Type (including charset and name), 292 Content-Disposition (including filename), and 293 Content-Transfer-Encoding. Furthermore, it must be defined, how a 294 public key should be included. 296 G3: To foster wide implementation of the new solution, it shall be 297 easily implementable. Unless needed for maximizing protection and 298 privacy, existing implementations shall not require substantial 299 changes in the existing code base. In particular also MIME 300 libraries widely used shall not need to be changed to comply with 301 the new mechanism for HP. 303 G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in 304 particular downgrade attacks, are mitigated as good as possible. 306 4.1.1. Sending Side 308 GS1: Determine which Header Fields (HFs) should or must be protected 309 at least for all protection levels. 311 GS2: Determine which HFs should or must be sent in clear of an 312 encrypted email. 314 GS3: Determine which HF should not or must not be included in the 315 visible header (for transport) of an encrypted email, with the 316 default being that whatever is not needed from GS2 is not put 317 into the unencrypted transport headers, thus fulfilling data 318 minimization requirements (including data spareness and hiding 319 of all information that technically can be hidden). 321 4.1.2. Receiving Side 323 GR1: Determine how HF should be displayed to the user in case of 324 conflicting information between the protected and unprotected 325 headers. 327 GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in 328 particular downgrade attacks, can be detected. 330 4.2. Additional Requirements for Backward-Compatibility With Legacy 331 Clients Unaware of Header Protection 333 This sub-section addresses the use cases 2) - 4) (cf. Section 3.1) 335 B1: Depending on the solution, define a means to distinguish between 336 forwarded messages and encapsulated messages using new HP 337 mechanism. 339 4.2.1. Sending side 341 BS1: Define how full HP support can be indicated to outgoing 342 messages. 344 BS2: Define how full HP support of the receiver can be detected or 345 guessed. 347 BS3: Ensure a HP unaware receiving side easily can display the 348 "Subject" HF to the user. 350 4.2.2. Receiving side 352 BR1: Define how full HP support can be detected in incoming messages. 354 4.3. Additional Requirements for Backward-Compatibility with Legacy 355 Header Protection Systems (if supported) 357 This sub-section addresses the use cases 5) - 9) (cf. Section 3.1). 359 LS1: Depending on the solution, define a means to distinguish between 360 forwarded messages, legacy encapsulated messages, and 361 encapsulated messages using new HP mechanism. 363 LS2: The solution should be backward compatible to existing solutions 364 and aim to minimize the implementation effort to include support 365 for existing solutions. 367 4.3.1. Sending Side 369 LSS1: Determine how legacy HP support can be indicated to outgoing 370 messages. 372 LSS2: Determine how legacy HP support of the receiver can be detected 373 or guessed. 375 4.3.2. Receiving Side 377 LSR1: Determine how legacy HP support can be detected in incoming 378 messages. 380 5. Message Format for progressive header disclosure 382 5.1. Design principles 384 pretty Easy privacy (pEp) is working on bringing state-of-the-art 385 automatic cryptography known from areas like TLS to electronic mail 386 (email) communication. pEp is determined to evolve the existing 387 standards as fundamentally and comprehensively as needed to gain easy 388 implementation and integration, and for easy use for regular Internet 389 users. pEp for email wants to attaining to good security practice 390 while still retaining backward compatibility for implementations 391 widespread. 393 To provide the required stability as a foundation for good security 394 practice, pEp for email defines a fixed MIME structure for its 395 innermost message structure, so to remove most attack vectors which 396 have permitted the numerous EFAIL vulnerabilities. (TBD: ref) 398 Security comes just next after privacy in pEp, for which reason the 399 application of signatures without encryption to messages in transit 400 is not considered purposeful. pEp for email herein referenced, and 401 further described in [I-D.marques-pep-email], either expects to 402 transfer messages in cleartext without signature or encryption, or 403 transfer them encrypted and with enclosed signature and necessary 404 public keys so that replies can be immediately upgraded to encrypted 405 messages. 407 The pEp message format is equivalent to the S/MIME standard in 408 ensuring header protection, in that the whole message is protected 409 instead, by wrapping it and providing cryptographic services to the 410 whole original message. The pEp message format is different compared 411 to the S/MIME standard in that the pEp protocols propose 412 opportunistic end-to-end security and signature, by allowing the 413 transport of the necessary public key material along with the 414 original messages. 416 For the purpose of allowing the insertion of such public keys, the 417 root entity of the protected message is thus nested once more into an 418 additional multipart/mixed MIME entity. The current pEp proposal is 419 for PGP/MIME, while an extension to S/MIME is next. 421 pEp's proposal is strict in that it requires that the cryptographic 422 services applied to the protected message MUST include encryption. 423 It also mandates a fixed MIME structure for the protected message, 424 which always MUST include a plaintext and optionally an HTML 425 representation (if HTML is used) of the same message, and requires 426 that all other optional elements to be eventually presented as 427 attachments. Alternatively the whole protected message could 428 represent in turn a wrapped pEp wrapper, which makes the message 429 structure fully recursive on purpose (e.g., for the purpose of 430 anonymization through onion routing). 432 For the purpose of implementing mixnet routing for email, it is 433 foreseen to nest pEp messages recursively. A protected message can 434 in turn contain a protected message due for forwarding. This is for 435 the purpose to increase privacy and counter the necessary leakage of 436 plaintext addressing in the envelope of the email. 438 The recursive nature of the pEp message format allows for the 439 implementation of progressive disclosure of the necessary transport 440 relevant header fields just as-needed to the next mail transport 441 agents along the transmission path. 443 5.2. Compatibility 445 The pEp message format version 2 is designed such that a receiving 446 Mail User Agent (MUA), which is OpenPGP-compliant but not pEp- 447 compliant, still has built-in capability to properly verify the 448 integrity of the mail, decode it and display all information of the 449 original mail to the user. The recovered protected message is 450 selfsufficiently described, including all protected header fields. 452 The pEp message format version 2 (as used by all the various pEp 453 implementations, cf. Section 10) is similar to what is standardized 454 for S/MIME in [RFC5751] and its successor 455 [I-D.ietf-lamps-rfc5751-bis]: 457 In order to protect outer, non-content-related message header 458 fields (for instance, the "Subject", "To", "From", and "Cc" 459 fields), the sending client MAY wrap a full MIME message in a 460 message/rfc822 wrapper in order to apply S/MIME security services 461 to these header fields. It is up to the receiving client to 462 decide how to present this "inner" header along with the 463 unprotected "outer" header. 465 When an S/MIME message is received, if the top-level protected 466 MIME entity has a Content-Type of message/rfc822, it can be 467 assumed that the intent was to provide header protection. This 468 entity SHOULD be presented as the top-level message, [...]. 470 5.3. Inner message 472 The pEp message format requires the innermost protected message to 473 follow a fixed MIME structure and to consist of exactly one human- 474 readable message which is represented in plain or HTML format. Both 475 plain and html entities MUST represent the same message to the user. 476 Any attachment to the message must be laid out in a flat list. No 477 additional multipart entities are allowed in the pEp message. 479 These restrictions permit to build mail user agents which are immune 480 to the EFAIL attacks. 482 This message is herein further referred to as the "pEp inner 483 message". 485 A mail user agent wanting to follow this standard, SHOULD transform 486 any "original message" into a "pEp inner message" for safe 487 representation on the receiving side. 489 5.4. Content-Type property "forwarded" 491 One caveat of the design is that the user interaction with message/ 492 rfc822 entities varies considerably across different mail user 493 agents. No standard is currently available which enables MUAs to 494 reliably determine whenever a nested message/rfc822 entity is meant 495 to blend the containing message, or if it was effectively intended to 496 be forwarded as a file document. pEp currently intends to implement 497 the proposal described by [I-D.melnikov-lamps-header-protection], 498 3.2, which defines a new Content-Type header field parameter with 499 name "forwarded", for the MUA to distinguish between a forwarded 500 message and a nested message for the purpose of header protection, 501 i.e., using "forwarded=no". 503 5.5. Outer message 505 With pEp message format version 2, the pEp standardized message is 506 equally wrapped in a message/rfc822 entity, but this time being in 507 turn wrapped in a multipart/mixed entity. The purpose of the 508 additional nesting is to allow for public keys of the sender to be 509 stored alongside the original message while being protected by the 510 same mechanism. 512 For the case of PGP/MIME, the currently only implemented MIME 513 encryption protocol implemented in pEp, the top-level entity called 514 the "outer message" MUST contain: 516 o exactly one entity of type message/rfc822, and 518 o one or more entity of type application/pgp-keys 520 Notes on the current pEp client implementations: 522 o the current pEp implementation also adds a text/plain entity 523 containing "pEp-Wrapped-Message-Info: OUTER" as first element in 524 the MIME tree. This element is not strictly necessary, but is in 525 place for better backwards compatibility when manually navigating 526 the nested message structure. This is part of the study of 527 various solutions to maximize backwards compatibility, and has 528 been omitted from the following examples. 530 o the current pEp implementation prepends "pEp-Wrapped-Message-Info: 531 INNER" to the original message body. This is an 532 implementation detail which should be ignored, and has been 533 omitted in the following examples. 535 o the current pEp implementation may render a text/plain directly in 536 place of the multipart/alternate, when no HTML representation was 537 generated by the sending MUA. This is not strict according to 538 pEp's own specification, and is currently being investigated. 540 This is an example of the top-level MIME entity, before being 541 encrypted and signed: 543 MIME-Version: 1.0 544 Content-Type: multipart/mixed; 545 boundary="6b8b4567327b23c6643c986966334873" 547 --6b8b4567327b23c6643c986966334873 548 Content-Type: message/rfc822; forwarded="no" 550 From: John Doe 551 To: Mary Smith 552 Subject: Example 553 Date: Fri, 30 Jun 2018 09:55:06 +0200 554 Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy> 555 X-Pep-Version: 2.0 556 MIME-Version: 1.0 557 Content-Type: multipart/alternative; 558 boundary="29fe9d2b2d7f6a703c1bffc47c162a8c" 560 --29fe9d2b2d7f6a703c1bffc47c162a8c 561 Content-Type: text/plain; charset="utf-8" 562 Content-Transfer-Encoding: quoted-printable 563 Content-Disposition: inline; filename="msg.txt" 565 p=E2=89=A1p for Privacy by Default. 566 -- =20 567 Sent from my p=E2=89=A1p for Android. 569 --29fe9d2b2d7f6a703c1bffc47c162a8c 570 Content-Type: text/html; charset="utf-8" 571 Content-Transfer-Encoding: quoted-printable 573 p=E2=89=A1p for Privacy by Default.
574 --
575 Sent from my p=E2=89=A1p for Android.
577 --29fe9d2b2d7f6a703c1bffc47c162a8c-- 578 --6b8b4567327b23c6643c986966334873 579 Content-Type: application/pgp-keys 580 Content-Disposition: attachment; filename="pEpkey.asc" 582 -----BEGIN PGP PUBLIC KEY BLOCK----- 584 ... 585 -----END PGP PUBLIC KEY BLOCK----- 587 --6b8b4567327b23c6643c986966334873-- 589 5.6. Transport message 591 In pEp message format 2 the "outer message" consists of a full RFC822 592 message with body and a minimal set of header fields, just those 593 necessary to conform to MIME multipart standards. 595 The "outer message" should be encrypted and carry a signature 596 according to the MIME encryption standards. The resulting message is 597 the transport message which a root entity of type multipart/ 598 encrypted. 600 A minimal set of header fields should be set on the "transport 601 message", as to permit delivery, without disclosing private 602 information. 604 The structure of the transport message may be altered in-transit, 605 e.g. through mailing list agents, or inspection gateways. 607 Signing and encrypting a message with MIME Security with OpenPGP 608 [RFC3156], yields a message with the following complete MIME 609 structure, seen across the encryption layer: 611 = multipart/encrypted; protocol="application/pgp-encrypted"; 612 + application/pgp-encrypted [ Version: 1 ] 613 + application/octet-stream; name="msg.asc" 614 { 615 Content-Disposition: inline; filename="msg.asc"; 616 } 617 | 618 [ opaque encrypted structure ] 619 | 620 { minimal headers } 621 + multipart/mixed 622 + message/rfc822; forwarded="no"; 623 | 624 { protected message headers } 625 + multipart/mixed 626 + multipart/alternate 627 + text/plain 628 + text/html 629 + application/octet-stream [ attachmet_1 ] 630 + application/octet-stream [ attachmet_2 ] 631 + application/pgp-keys 633 The header fields of the sub-part of type application/octet-stream 634 SHOULD be modified to ensure that: 636 o the Content-Type header field's 638 * "name" parameter is set to the value "msg.asc", and 640 * parameter "forwarded" is set to "no", and 642 o the Content-Disposition header field value is set to "inline" 644 * and the "filename" parameter is set to "msg.asc". 646 5.7. S/MIME Compatibility 648 Interoperability and implementation symmetry between PGP/MIME and 649 S/MIME is on the roadmap of pEp. 651 6. Candidate Header Fields for Header Protection 653 By default, all headers of the original message SHOULD be wrapped 654 with the original message, with one exception: 656 o the header field "Bcc" MUST NOT be added to the protected headers. 658 7. Stub Outside Headers 660 The outer message requires a minimal set of headers to be in place 661 for being eligible for transport. This includes the "From", "To", 662 "Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol 663 hereby defined also depends on the "MIME-Version", "Content-Type", 664 "Content-Disposition" and eventually the "Content-Transport-Encoding" 665 header field to be present. 667 Submission and forwarding based on SMTP carries "from" and 668 "receivers" information out-of-band, so that the "From" and "To" 669 header fields are not strictly necessary. Nevertheless, "From", 670 "Date", and at least one destination header field is mandatory as per 671 [RFC5322]. They SHOULD be conserved for reliability. 673 The following header fields should contain a verbatim copy of the 674 header fields of the inner message: 676 o Date 678 o From 680 o To 682 o Cc (*) 683 o Bcc (*) 685 The entries with an asterisk mark (*) should only be set if also 686 present in the original message. 688 Clients which follow pEp standards MUST set the header field value 689 for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which 690 do not adhere to all pEp standards should set the header field value 691 of "Subject" to a descriptive stub value. An example used in 692 practice is 694 o Subject: Encrypted message 696 The following header fields MUST be initialized with proper values 697 according to the MIME standards: 699 o Content-Type 701 o Content-Disposition 703 o Content-Transport-Encoding (if necessary) 705 8. Processing Incoming Email under Progressive Header Disclosure 707 [[ TODO ]] 709 8.1. Resolving Conflicting Protected and Unprotected Header Fields 711 Header field values from the transport message MUST NOT be shown, 712 when displaying the inner message, or the outer message. The inner 713 message MUST carry all relevant header fields necessary for display. 715 8.2. Processing of Signed-only Email 717 pEp either engages in a signed-and-encrypted communication or in an 718 unsigned plaintext communication. Inbound signatures attached to 719 plaintext messages are duly verified but cannot enhance the perceived 720 quality of the message in the user interface (while an invalid 721 signature degrades the perception) [I-D.birk-pep]. 723 8.3. Incoming Filter Processing 725 The Mail User Agent may implement outgoing filtering of mails, which 726 may veto, alter, redirect or replicate the messages. The 727 functionality may be implemented on the mailbox server and be 728 configurable through a well-known protocol, e.g., by means of The 729 Sieve Mail-Filtering Language [RFC5490], or be implemented client- 730 side, or in a combination of both. 732 A mailbox server, which is required to process the full range of 733 possible filters, is requiring plaintext access to the header fields. 735 In an end-to-end-encryption context, which pEp enforces by default, 736 upon first reception of the message the mailbox server is limited to 737 see the transport- relevant headers of the outer wrapper message. A 738 pEp client configured to trust the server ("trusted server" setting 739 [I-D.marques-pep-email]) will later download the encrypted message, 740 decrypt it and replace the copy on the server by the decrypted copy. 742 8.3.1. Staged Filtering of Inbound Messages 744 Inbound messages are expected to be delivered to the inbox while 745 still being encrypted. At this point in time, server-side filtering 746 can only evaluate the unprotected header fields in the wrapper 747 message. 749 In an end-to-end-encryption context, which pEp enforces by default, 750 the mailbox server is limited to see the transport-relevant headers 751 of the outer wrapper message only upon first delivery. A pEp client 752 configured to trust the server ("trusted server" setting 753 [I-D.marques-pep-email]) will eventually download the encrypted 754 message, decrypt it locally and replace the copy on the server by the 755 decrypted copy. Server-side message filters SHOULD be able to detect 756 such post-processed messages, and apply the pending filters. The 757 client SHOULD easily reflect the post-filtered messages in the user 758 interface. 760 8.4. Outgoing Filter Processing 762 The Mail User Agent may implement outgoing filtering of emails, which 763 may veto, alter or replicate the email. They may also hint the MUA 764 to store a copy in an alternate "Sent" folder. 766 Filters which veto the sending or do alter the mail or replicate it 767 (e.g., mass-mail generators) SHOULD be completed prior to applying 768 protection, and thus also prior to applying header protection. 769 Redirection to alternate "Sent" folders MUST NOT be decided prior to 770 applying protection, but MUAs MAY abide from this restriction if they 771 implement the "trusted server" option and the option is selected for 772 the specific mailbox server; in this case, MUAs MUST NOT allow to 773 redirect a message to an untrusted server by these rules, to prevent 774 information leakage to the untrusted server. 776 [[ TODO: Mention implicit filter for minimal color-rating for message 777 replication. ]] 779 [[ TODO: How to produce key-export-mails manually this way? That is, 780 what about non-pEp-mode? ]] 782 9. Security Considerations 784 [[ TODO ]] 786 10. Implementation Status 788 10.1. Introduction 790 This section records the status of known implementations of the 791 protocol defined by this specification at the time of posting of this 792 Internet-Draft, and is based on a proposal described in [RFC7942]. 793 The description of implementations in this section is intended to 794 assist the IETF in its decision processes in progressing drafts to 795 RFCs. Please note that the listing of any individual implementation 796 here does not imply endorsement by the IETF. Furthermore, no effort 797 has been spent to verify the information presented here that was 798 supplied by IETF contributors. This is not intended as, and must not 799 be construed to be, a catalog of available implementations or their 800 features. Readers are advised to note that other implementations may 801 exist. 803 According to [RFC7942], "[...] this will allow reviewers and working 804 groups to assign due consideration to documents that have the benefit 805 of running code, which may serve as evidence of valuable 806 experimentation and feedback that have made the implemented protocols 807 more mature. It is up to the individual working groups to use this 808 information as they see fit." 810 10.2. Current software implementing pEp 812 The following software implementing the pEp protocols (to varying 813 degrees) already exists: 815 o pEp for Outlook as add-on for Microsoft Outlook, release 816 [SRC.pepforoutlook] 818 o pEp for Android (based on a fork of the K9 MUA), release 819 [SRC.pepforandroid] 821 o Enigmail/pEp as add-on for Mozilla Thunderbird, release 822 [SRC.enigmailpep] 824 o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios] 825 pEp for Android, iOS and Outlook are provided by pEp Security, a 826 commercial entity specializing in end-user software implementing pEp 827 while Enigmail/pEp is pursued as community project, supported by the 828 pEp Foundation. 830 All software is available as Free Software and published also in 831 source form. 833 11. Acknowledgements 835 Special thanks go to Krista Bennett and Volker Birk for valuable 836 input to this draft and Hernani Marques for reviewing. 838 12. References 840 12.1. Normative References 842 [I-D.birk-pep] 843 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 844 Privacy by Default", draft-birk-pep-03 (work in progress), 845 March 2019. 847 [I-D.ietf-lamps-rfc5751-bis] 848 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 849 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 850 Message Specification", draft-ietf-lamps-rfc5751-bis-12 851 (work in progress), September 2018. 853 [I-D.marques-pep-email] 854 Marques, H., "pretty Easy privacy (pEp): Email Formats and 855 Protocols", draft-marques-pep-email-02 (work in progress), 856 October 2018. 858 [I-D.melnikov-lamps-header-protection] 859 Melnikov, A., "Considerations for protecting Email header 860 with S/MIME", draft-melnikov-lamps-header-protection-00 861 (work in progress), October 2018. 863 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 864 Extensions (MIME) Part Two: Media Types", RFC 2046, 865 DOI 10.17487/RFC2046, November 1996, 866 . 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, 870 DOI 10.17487/RFC2119, March 1997, 871 . 873 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 874 "MIME Security with OpenPGP", RFC 3156, 875 DOI 10.17487/RFC3156, August 2001, 876 . 878 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 879 Thayer, "OpenPGP Message Format", RFC 4880, 880 DOI 10.17487/RFC4880, November 2007, 881 . 883 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 884 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 885 . 887 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 888 DOI 10.17487/RFC5322, October 2008, 889 . 891 [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- 892 Extensions for Checking Mailbox Status and Accessing 893 Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 894 2009, . 896 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 897 Mail Extensions (S/MIME) Version 3.2 Message 898 Specification", RFC 5751, DOI 10.17487/RFC5751, January 899 2010, . 901 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 902 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 903 RFC 6376, DOI 10.17487/RFC6376, September 2011, 904 . 906 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 907 Authorizing Use of Domains in Email, Version 1", RFC 7208, 908 DOI 10.17487/RFC7208, April 2014, 909 . 911 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 912 Message Authentication, Reporting, and Conformance 913 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 914 . 916 12.2. Informative References 918 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 919 Code: The Implementation Status Section", BCP 205, 920 RFC 7942, DOI 10.17487/RFC7942, July 2016, 921 . 923 [SRC.enigmailpep] 924 "Source code for Enigmail/pEp", March 2019, 925 . 927 [SRC.pepforandroid] 928 "Source code for pEp for Android", March 2019, 929 . 931 [SRC.pepforios] 932 "Source code for pEp for iOS", March 2019, 933 . 935 [SRC.pepforoutlook] 936 "Source code for pEp for Outlook", March 2019, 937 . 939 Appendix A. Document Changelog 941 [[ RFC Editor: This section is to be removed before publication ]] 943 o draft-luck-lamps-pep-header-protection 945 * Initial version 947 Appendix B. Open Issues 949 [[ RFC Editor: This section should be empty and is to be removed 950 before publication. ]] 952 o Align with specification for MIME Content-Type message/partial 954 * We probably have issues and overlapping specifications about 955 encoding for nested message/rfc822 entities, specified in 956 [RFC2046]. Further study is needed to find and understand the 957 issues. 959 o Signed-only protection needs further study 961 * pEp only does header protection by applying both signing and 962 encryption. Technically it is also possible to sign, but not 963 encrypt the protected messages. This needs further study. 965 Authors' Addresses 967 Claudio Luck 968 pEp Foundation 969 Oberer Graben 4 970 CH-8400 Winterthur 971 Switzerland 973 Email: claudio.luck@pep.foundation 974 URI: https://pep.foundation/ 976 Bernie Hoeneisen 977 Ucom Standards Track Solutions GmbH 978 CH-8046 Zuerich 979 Switzerland 981 Phone: +41 44 500 52 44 982 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 983 URI: https://ucom.ch/