idnits 2.17.1 draft-dkg-lamps-e2e-mail-guidance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 67 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Aside from this cryptographic summary, the message itself should be rendered as though the Cryptographic Payload is the body of the message. The Cryptographic Layers themselves SHOULD not be rendered otherwise. -- The document date (31 October 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-dkg-lamps-samples-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lamps D.K. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational 31 October 2020 5 Expires: 4 May 2021 7 Guidance on End-to-End E-mail Security 8 draft-dkg-lamps-e2e-mail-guidance-00 10 Abstract 12 End-to-end cryptographic protections for e-mail messages can provide 13 useful security. However, the standards for providing cryptographic 14 protection are extremely flexible. That flexibility can trap users 15 and cause surprising failures. This document offers guidance for 16 mail user agent implementers that need to compose or interpret e-mail 17 messages with end-to-end cryptographic protection. It provides a 18 useful set of vocabulary as well as suggestions to avoid common 19 failures. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 4 May 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4 58 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 4 60 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 5 61 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 5 62 4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 5 63 4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 6 64 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 7 65 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 7 66 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 7 67 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 8 68 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 8 69 4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 8 70 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 8 71 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 9 72 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 10 74 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 11 75 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 11 76 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 12 77 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 12 78 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 12 79 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 13 80 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 13 81 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 14 82 6.3. Forwarded Messages with Cryptographic Protection . . . . 15 83 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 16 84 7. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 10. Document Considerations . . . . . . . . . . . . . . . . . . . 17 88 10.1. Document History . . . . . . . . . . . . . . . . . . . . 17 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 12.2. Informative References . . . . . . . . . . . . . . . . . 18 93 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 19 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 E-mail end-to-end security using S/MIME [RFC8551] and PGP/MIME 99 [RFC3156] cryptographic standards can provide integrity, 100 authentication and confidentiality to MIME e-mail messages [RFC4289]. 102 However, there are many ways that a receiving mail user agent can 103 misinterpret or accidentally break these security guarantees (e.g., 104 [EFAIL]). 106 A mail user agent that interprets a message with end-to-end 107 cryptographic protections needs to do so defensively, staying alert 108 to different ways that these protections can be bypassed by mangling 109 (either malicious or accidental) or a failed user experience. 111 A mail user agent that generates a message with end-to-end 112 cryptographic protections should be aware of these defensive 113 interpretation strategies, and should compose any new outbound 114 message conservatively if they want the protections to remain intact. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 122 capitals, as shown here. 124 1.2. Terminology 126 For the purposes of this document, we define the following concepts: 128 * _MUA_ is short for Mail User Agent; an e-mail client. 130 * _Protection_ of message data refers to cryptographic encryption 131 and/or signatures, providing confidentiality, authenticity, and/or 132 integrity. 134 * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic 135 Payload_, and _Errant Cryptographic Layer_ are defined in 136 Section 4 138 * A _well-formed_ e-mail message with cryptographic protection has 139 both a _Cryptographic Envelope_ and a _Cryptographic Payload_, 141 * _Structural Headers_ are documented in Section 1.2.1. 143 1.2.1. Structural Headers 145 A message header whose name begins with "Content-" is referred to in 146 this document as a "structural" header. 148 These headers indicate something about the specific MIME part they 149 are attached to, and cannot be transferred or copied to other parts 150 without endangering the readability of the message. 152 This includes (but is not limited to): 154 * "Content-Type" 156 * "Content-Transfer-Encoding" 158 * "Content-Disposition" 160 FIXME: are there any non-"Content-*" headers we should consider as 161 structural? 163 2. Usability 165 The end user (the operator of the MUA) is unlikely to understand 166 complex end-to-end cryptographic protections on any e-mail message, 167 so keep it simple. 169 For clarity to the user, any cryptographic protections should apply 170 to the message as a whole, not just to some subparts. 172 This is true for message composition: the standard message 173 composition user interface of an MUA should offer minimal controls 174 which indicate which types of protection to apply to the new message 175 as a whole. 177 This is also true for message interpretation: the standard message 178 rendering user interface of an MUA should offer a minimal, clear 179 indicator about the end-to-end cryptographic status of the message as 180 a whole. 182 3. Types of Protection 184 A given message might be: 186 * signed, 188 * encrypted, or 190 * both signed and encrypted. 192 Given that many e-mail messages offer no cryptographic protections, 193 the user needs to be able to detect which protections are present for 194 any given message. 196 4. Cryptographic MIME Message Structure 198 Implementations use the structure of an e-mail message to protect the 199 headers. This section establishes some conventions about how to 200 think about message structure. 202 4.1. Cryptographic Layers 204 "Cryptographic Layer" refers to a MIME substructure that supplies 205 some cryptographic protections to an internal MIME subtree. The 206 internal subtree is known as the "protected part" though of course it 207 may itself be a multipart object. 209 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 210 indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) 211 indicates "unwraps to". 213 4.1.1. S/MIME Cryptographic Layers 215 For S/MIME [RFC8551], there are four forms of Cryptographic Layers: 216 multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 217 authEnveloped-data. 219 4.1.1.1. S/MIME Multipart Signed Cryptographic Layer 221 └┬╴multipart/signed; protocol="application/pkcs7-signature" 222 ├─╴[protected part] 223 └─╴application/pkcs7-signature 225 This MIME layer offers authentication and integrity. 227 4.1.1.2. S/MIME PKCS7 signed-data Cryptographic Layer 229 └─╴application/pkcs7-mime; smime-type="signed-data" 230 ⇩ (unwraps to) 231 └─╴[protected part] 233 This MIME layer offers authentication and integrity. 235 4.1.1.3. S/MIME PKCS7 enveloped-data Cryptographic Layer 237 └─╴application/pkcs7-mime; smime-type="enveloped-data" 238 ↧ (decrypts to) 239 └─╴[protected part] 241 This MIME layer offers confidentiality. 243 4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer 245 └─╴application/pkcs7-mime; smime-type="authEnveloped-data" 246 ↧ (decrypts to) 247 └─╴[protected part] 249 This MIME layer offers confidentiality and integrity. 251 Note that "enveloped-data" (Section 4.1.1.3) and "authEnveloped-data" 252 (Section 4.1.1.4) have identical message structure and semantics. 253 The only difference between the two is ciphertext malleability. 255 The examples in this document only include "enveloped-data", but the 256 implications for that layer apply to "authEnveloped-data" as well. 258 4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer 260 The Cryptographic Message Syntax (CMS) provides a MIME compression 261 layer ("smime-type="compressed-data""), as defined in [RFC3274]. 262 While the compression layer is technically a part of CMS, it is not 263 considered a Cryptographic Layer for the purposes of this document. 265 4.1.2. PGP/MIME Cryptographic Layers 267 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 268 signing and encryption. 270 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 272 └┬╴multipart/signed; protocol="application/pgp-signature" 273 ├─╴[protected part] 274 └─╴application/pgp-signature 276 This MIME layer offers authenticity and integrity. 278 4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 279 └┬╴multipart/encrypted 280 ├─╴application/pgp-encrypted 281 └─╴application/octet-stream 282 ↧ (decrypts to) 283 └─╴[protected part] 285 Note that for PGP/MIME, this MIME layer can offer any of: 287 * confidentiality (via a Symmetrically Encrypted Data Packet, see 288 Section 5.7 of [RFC4880]; a MUA MUST NOT generate this form due to 289 ciphertext malleability) 291 * confidentiality and integrity (via a Symmetrically Encrypted 292 Integrity Protected Data Packet (SEIPD), see section 5.13 of 293 [RFC4880]), or 295 * confidentiality, integrity, and authenticity all together (by 296 including an OpenPGP Signature Packet within the SEIPD). 298 4.2. Cryptographic Envelope 300 The Cryptographic Envelope is the largest contiguous set of 301 Cryptographic Layers of an e-mail message starting with the outermost 302 MIME type (that is, with the Content-Type of the message itself). 304 If the Content-Type of the message itself is not a Cryptographic 305 Layer, then the message has no cryptographic envelope. 307 "Contiguous" in the definition above indicates that if a 308 Cryptographic Layer is the protected part of another Cryptographic 309 Layer, the layers together comprise a single Cryptographic Envelope. 311 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 312 Layers within the non-Cryptographic Layer _are not_ part of the 313 Cryptographic Envelope. They are Errant Cryptographic Layers (see 314 Section 4.5). 316 Note also that the ordering of the Cryptographic Layers implies 317 different cryptographic properties. A signed-then-encrypted message 318 is different than an encrypted-then-signed message. See Section 5.2. 320 4.3. Cryptographic Payload 322 The Cryptographic Payload of a message is the first non-Cryptographic 323 Layer - the "protected part" - within the Cryptographic Envelope. 325 4.4. Types of Cryptographic Envelope 326 4.4.1. Simple Cryptographic Envelopes 328 As described above, if the "protected part" identified in the sction 329 above is not itself a Cryptographic Layer, that part _is_ the 330 Cryptographic Payload. 332 If the application wants to generate a message that is both encrypted 333 and signed, it MAY use the simple MIME structure from Section 4.1.2.2 334 by ensuring that the [RFC4880] Encrypted Message within the 335 "application/octet-stream" part contains an [RFC4880] Signed Message 336 (the final option described in Section 4.1.2.2. 338 4.4.2. Multilayer Cryptographic Envelopes 340 It is possible to construct a Cryptographic Envelope consisting of 341 multiple layers with either S/MIME or PGP/MIME , for example using 342 the following structure: 344 A └─╴application/pkcs7-mime; smime-type="enveloped-data" 345 B ↧ (decrypts to) 346 C └─╴application/pkcs7-mime; smime-type="signed-data" 347 D ⇩ (unwraps to) 348 E └─╴[protected part] 350 When handling such a message, the properties of the Cryptographic 351 Envelope are derived from the series "A", "C". 353 As noted in Section 4.4.1, PGP/MIME applications also have a simpler 354 MIME construction available with the same cryptographic properties. 356 4.5. Errant Crytptographic Layers 358 Due to confusion, malice, or well-intentioned tampering, a message 359 may contain a Cryptographic Layer that is not part of the 360 Cryptographic Envelope. Such a layer is an Errant Cryptographic 361 Layer. 363 An Errant Cryptographic Layer SHOULD NOT contribute to the message's 364 overall cryptographic state. 366 Guidance for dealing with Errant Cryptographic Layers can be found in 367 Section 6.2. 369 4.5.1. Mailing List Wrapping 371 Some mailing list software will re-wrap a well-formed signed message 372 before re-sending to add a footer, resulting in the following 373 structure seen by recipients of the e-mail: 375 H └┬╴multipart/mixed 376 I ├┬╴multipart/signed 377 J │├─╴text/plain 378 K │└─╴application/pgp-signature 379 L └─╴text/plain 381 In this message, "L" is the footer added by the mailing list. "I" is 382 now an Errant Cryptographic Layer. 384 Note that this message has no Cryptographic Envelope at all. 386 It is NOT RECOMMENDED to produce e-mail messages with this structure, 387 because the data in part "L" may appear to the user as though it were 388 part of "J", though they have different cryptographic properties. In 389 particular, if the user believes that the message is signed, but 390 cannot distinguish "L" from "J" then the author of "L" can 391 effectively tamper with content of the signed message, breaking the 392 user's expectation of integrity and authenticity. 394 4.5.2. A Baroque Example 396 Consider a message with the following overcomplicated structure: 398 M └┬╴multipart/encrypted 399 N ├─╴application/pgp-encrypted 400 O └─╴application/octet-stream 401 P ↧ (decrypts to) 402 Q └┬╴multipart/signed 403 R ├┬╴multipart/mixed 404 S │├┬╴multipart/signed 405 T ││├─╴text/plain 406 U ││└─╴application/pgp-signature 407 V │└─╴text/plain 408 W └─╴application/pgp-signature 410 The 3 Cryptographic Layers in such a message are rooted in parts "M", 411 "Q", and "S". But the Cryptographic Envelope of the message consists 412 only of the properties derived from the series "M", "Q". The 413 Cryptographic Payload of the message is part "R". Part "S" is an 414 Errant Cryptographic Layer. 416 Note that this message has both a Cryptographic Envelope _and_ an 417 Errant Cryptographic Layer. 419 It is NOT RECOMMENDED to generate messages with such complicated 420 structures. Even if a receiving MUA can parse this structure 421 properly, it is nearly impossible to render in a way that the user 422 can reason about the cryptographic properties of part "T" compared to 423 part "V". 425 5. Message Composition 427 This section describes the ideal composition of an e-mail message 428 with end-to-end cryptographic protection. A message composed with 429 this form is most likely to achieve its end-to-end security goals. 431 5.1. Message Composition Algorithm 433 This section roughly describes the steps that a MUA should use to 434 compose a cryptographically-protected message that has a proper 435 cryptographic envelope and payload. 437 The message composition algorithm takes three parameters: 439 * "origbody": the traditional unprotected message body as a well- 440 formed MIME tree (possibly just a single MIME leaf part). As a 441 well-formed MIME tree, "origbody" already has structural headers 442 present (see Section 1.2.1). 444 * "origheaders": the intended non-structural headers for the 445 message, represented here as a table mapping from header names to 446 header values.. For example, "origheaders['From']" refers to the 447 value of the "From" header that the composing MUA would typically 448 place on the message before sending it. 450 * "crypto": The series of cryptographic protections to apply (for 451 example, "sign with the secret key corresponding to X.509 452 certificate X, then encrypt to X.509 certificates X and Y"). This 453 is a routine that accepts a MIME tree as input (the Cryptographic 454 Payload), wraps the input in the appropriate Cryptographic 455 Envelope, and returns the resultant MIME tree as output. 457 The algorithm returns a MIME object that is ready to be injected into 458 the mail system: 460 * Apply "crypto" to "origbody", yielding MIME tree "output" 462 * For header name "h" in "origheaders": 464 - Set header "h" of "output" to "origheaders[h]" 466 * Return "output" 468 5.2. Encryption Outside, Signature Inside 470 Users expect any message that is both signed and encrypted to be 471 signed _inside_ the encryption, and not the other way around. 473 Putting the signature inside the encryption has two advantages: 475 * The details of the signature remain confidential, visible only to 476 the parties capable of decryption. 478 * Any mail transport agent that modifies the message is unlikely to 479 be able to accidentally break the signature. 481 A MUA SHOULD NOT generate an encrypted and signed message where the 482 only signature is outside the encryption. 484 5.3. Avoid Offering Encrypted-only Messages 486 When generating an e-mail, the user has options about what forms of 487 end-to-end cryptographic protections to apply to it. 489 In some cases, offering any end-to-end cryptographic protection is 490 harmful: it may confuse the recipient and offer no benefit. 492 In other cases, signing a message is useful (authenticity and 493 integrity are desirable) but encryption is either impossible (for 494 example, if the sender does not know how to encrypt to all 495 recipients) or meaningless (for example, an e-mail message to a 496 mailing list that is intended to be be published to a public 497 archive). 499 In other cases, full end-to-end confidentiality, authenticity, and 500 integrity are desirable. 502 It is unclear what the use case is for an e-mail message with end-to- 503 end confidentiality but without authenticity or integrity. 505 A reasonable MUA will keep its message composition interface simple, 506 so when presenting the user with a choice of cryptographic 507 protection, it SHOULD offer no more than three choices: 509 * no end-to-end cryptographic protection 511 * signing-only 513 * signed and encrypted 515 5.4. Composing a Reply Message 517 When replying to a message, most MUAs compose an initial draft of the 518 reply that contains quoted text from the original message. A 519 responsible MUA will take precautions to avoid leaking the cleartext 520 of an encrypted message in such a reply. 522 If the original message was end-to-end encrypted, the replying MUA 523 MUST either: 525 * compose the reply with end-to-end encryption, or 527 * avoid including quoted text from the original message. 529 In general, MUAs SHOULD prefer the first option: to compose an 530 encrypted reply. This is what users expect. 532 However, in some circumstances, the replying MUA cannot compose an 533 encrypted reply. For example, the MUA might not have a valid, 534 unexpired, encryption-capable certificate for all recipients. This 535 can also happen during composition when a user adds a new recipient 536 into the reply, or manually toggles the cryptographic protections to 537 remove encryption. 539 In this circumstance, the composing MUA SHOULD strip the quoted text 540 from the original message. 542 Note additional nuance about replies to malformed messages that 543 contain encryption in Section 6.2.2.1. 545 6. Message Interpretation 547 Despite the best efforts of well-intentioned senders to create e-mail 548 messages with well-formed end-to-end cryptographic protection, 549 receiving MUAs will inevitably encounter some messages with malformed 550 end-to-end cryptographic protection. 552 This section offers guidance on dealing with both well-formed and 553 malformed messages containing Cryptographic Layers. 555 6.1. Rendering Well-formed Messages 557 A message is well-formed when it has a Cryptographic Envelope, a 558 Cryptographic Payload, and no Errant Cryptographic Layers. Rendering 559 a well-formed message is straightforward. 561 The receiving MUA should evaluate and summarize the cryptographic 562 properties of the Cryptographic Envelope, and display that status to 563 the user in a secure, strictly-controlled part of the UI. In 564 particular, the part of the UI used to render the cryptographic 565 summary of the message MUST NOT be spoofable, modifiable, or 566 otherwise controllable by the received message itself. 568 Aside from this cryptographic summary, the message itself should be 569 rendered as though the Cryptographic Payload is the body of the 570 message. The Cryptographic Layers themselves SHOULD not be rendered 571 otherwise. 573 6.2. Errant Cryptographic Layers 575 If an incoming message has any Errant Cryptographic Layers, the 576 interpreting MUA SHOULD ignore those layers when rendering the 577 cryptographic summary of the message to the user. 579 6.2.1. Errant Signing Layer 581 When rendering a message with an Errant Cryptographic Layer that 582 provides authenticity and integrity (via signatures), the message 583 should be rendered by replacing the Cryptographic layer with the part 584 it encloses. 586 For example, a message with this structure: 588 A └┬╴multipart/mixed 589 B ├╴text/plain 590 C ├┬╴multipart/signed 591 D │├─╴image/jpeg 592 E │└─╴application/pgp-signature 593 F └─╴text/plain 595 Should be rendered identically to this: 597 A └┬╴multipart/mixed 598 B ├─╴text/plain 599 D ├─╴image/jpeg 600 F └─╴text/plain 602 In such a situation, an MUA SHOULD NOT indicate in the cryptographic 603 summary that the message is signed. 605 6.2.1.1. Exception: Mailing List Footers 607 The use case described in Section 4.5.1 is common enough in some 608 contexts, that a MUA MAY decide to handle it as a special exception. 610 If the MUA determines that the message comes from a mailing list (it 611 has a "List-ID" header), and it has a structure that appends a footer 612 to a signing-only Cryptographic Layer with a valid signature, such 613 as: 615 H └┬╴multipart/mixed 616 I ├┬╴multipart/signed 617 J │├─╴[protected part, may be arbitrary MIME subtree] 618 K │└─╴application/{pgp,pkcs7}-signature 619 L └─╴[footer, typically text/plain] 621 or: 623 H └┬╴multipart/mixed 624 I ├─╴application/pkcs7-mime; smime-type="signed-data" 625 │⇩ (unwraps to) 626 J │└─╴[protected part, may be an arbitrary MIME subtree] 627 L └─╴[footer, typically text/plain] 629 Then, the MUA MAY indicate to the user that this is a signed message 630 that has been wrapped by the mailing list. 632 In this case, the MUA MUST distinguish the footer (part "L") from the 633 protected part (part "J") when rendering any information about the 634 signature. 636 One way to do this is to offer the user two different views of the 637 message: the "mailing list" view, which hides any cryptographic 638 summary but shows the footer: 640 Cryptographic Protections: none 641 H └┬╴multipart/mixed 642 J ├─╴[protected part, may be arbitrary MIME subtree] 643 L └─╴[footer, typically text/plain] 645 or the "sender's view", which shows the cryptographic summary but 646 hides the footer: 648 Cryptographic Protections: signed [details from part I] 649 J └─╴[protected part, may be arbitrary MIME subtree] 651 6.2.2. Errant Encryption Layer 653 An MUA may encounter a message with an Errant Cryptographic Layer 654 that offers confidentiality (encryption), and the MUA is capable of 655 decrypting it. 657 The user wants to be able to see the contents of any message that 658 they receive, so an MUA in this situation SHOULD decrypt the part. 660 In this case, though, the MUA MUST NOT indicate in the message's 661 cryptographic summary that the message itself was encrypted. Such an 662 indication could be taken to mean that other (non-encrypted) parts of 663 the message arrived with cryptographic confidentiality. 665 6.2.2.1. Replying to a Message with an Errant Encryption Layer 667 Note that there is an asymmetry here between rendering and replying 668 to a message with an Errant Encryption Layer. 670 When rendering, the MUA does not indicate that the message was 671 encrypted, even if some subpart of it was decrypted for rendering. 673 But when composing a reply that contains quoted text from the 674 decrypted subpart, the reply message SHOULD be marked for encryption, 675 as noted in {#composing-reply}. 677 Alternately, if the reply message cannot be encrypted (or if the user 678 elects to not encrypt the reply), the composed reply MUST NOT include 679 any material from the decrypted subpart. 681 6.3. Forwarded Messages with Cryptographic Protection 683 An incoming e-mail message may include an attached forwarded message, 684 typically as a MIME subpart with "Content-Type: message/rfc822" 685 ([RFC5322]) or "Content-Type: message/global" ([RFC5355]). 687 Regardless of the cryptographic protections and structure of the 688 incoming message, the internal forwarded message may have its own 689 Cryptographic Envelope. 691 The Cryptographic Layers that are part of the Cryptographic Envelope 692 of the forwarded message are not Errant Cryptographic Layers of the 693 surrounding message - they are simply layers that apply to the 694 forwarded message itself. 696 The rendering MUA MUST NOT conflate the cryptographic protections of 697 the forwarded message with the cryptographic protections of the 698 incoming message. 700 The rendering MUA MAY render a cryptograpic summary of the 701 protections afforded to the forwarded message by its own 702 Cryptographic Envelope, as long as that rendering is unambiguously 703 tied to the forwarded message itself. 705 6.4. Signature failures 707 A cryptographic signature may fail in multiple ways. A receiving MUA 708 that discovers a failed signature should treat the message as though 709 the signature did not exist. This is similar to the standard 710 guidance for about failed DKIM signatures (see section 6.1 of 711 [RFC6376]). 713 A MUA SHOULD NOT render a message with a failed signature as more 714 dangerous or more dubious than a comparable message without any 715 signature at all. 717 A MUA that encounters an encrypted-and-signed message where the 718 signature is invalid SHOULD treat the message the same way that it 719 would treat a message that is encryption-only. 721 Some different ways that a signature may be invalid on a given 722 message: 724 * the signature is not cryptographically valid (the math fails). 726 * the signature relies on suspect cryptographic primitives (e.g. 727 over a legacy digest algorithm, or was made by a weak key, e.g., 728 1024-bit R.SA) 730 * the signature is made by a certificate which the receiving MUA 731 does not have access to. 733 * the certificate that made the signature was revoked. 735 * the certificate that made the signature was expired at the time 736 that the signature was made. 738 * the certificate that made the signature does not correspond to the 739 author of the message. 741 * the signature indicates that it was made at a time much before or 742 much after from the date of the message itself. 744 A valid signature must pass all these tests, but of course invalid 745 signatures may be invalid in more than one of the ways listed above. 747 7. Common Pitfalls and Guidelines 749 This section highlights a few "pitfalls" and guidelines based on 750 these discussions and lessons learned. 752 FIXME: some possible additional commentary on: 754 * indexing and search of encrypted messages 756 * managing access to cryptographic secret keys that require user 757 interaction 759 * secure deletion 761 * inline PGP, ugh 763 8. IANA Considerations 765 MAYBE: provide an indicator in the IANA header registry for which 766 headers are "structural" ? This is probably unnecessary. 768 9. Security Considerations 770 This entire document addresses security considerations about end-to- 771 end cryptographic protections for e-mail messages. 773 10. Document Considerations 775 [ RFC Editor: please remove this section before publication ] 777 This document is currently edited as markdown. Minor editorial 778 changes can be suggested via merge requests at 779 https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the author. 780 Please direct all significant commentary to the public IETF LAMPS 781 mailing list: spasm@ietf.org 783 10.1. Document History 785 11. Acknowledgements 787 The set of constructs and recommendations in this document are 788 derived from discussions with many different implementers, including 789 Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David 790 Bremner, Holger Krekel, Jameson Rollins, juga, Patrick Brunschwig, 791 and Vincent Breitmoser. 793 12. References 795 12.1. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, 799 DOI 10.17487/RFC2119, March 1997, 800 . 802 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 803 "MIME Security with OpenPGP", RFC 3156, 804 DOI 10.17487/RFC3156, August 2001, 805 . 807 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 808 Extensions (MIME) Part Four: Registration Procedures", 809 BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, 810 . 812 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 813 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 814 May 2017, . 816 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 817 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 818 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 819 April 2019, . 821 12.2. Informative References 823 [EFAIL] "EFAIL", n.d., . 825 [I-D.draft-bre-openpgp-samples-01] 826 Einarsson, B., juga, j., and D. Gillmor, "OpenPGP Example 827 Keys and Certificates", Work in Progress, Internet-Draft, 828 draft-bre-openpgp-samples-01, 20 December 2019, 829 . 832 [I-D.draft-dkg-lamps-samples-02] 833 Gillmor, D., "S/MIME Example Keys and Certificates", Work 834 in Progress, Internet-Draft, draft-dkg-lamps-samples-02, 835 24 December 2019, . 838 [RFC3274] Gutmann, P., "Compressed Data Content Type for 839 Cryptographic Message Syntax (CMS)", RFC 3274, 840 DOI 10.17487/RFC3274, June 2002, 841 . 843 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 844 Thayer, "OpenPGP Message Format", RFC 4880, 845 DOI 10.17487/RFC4880, November 2007, 846 . 848 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 849 DOI 10.17487/RFC5322, October 2008, 850 . 852 [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 853 and M. Holdrege, "Threats Introduced by Reliable Server 854 Pooling (RSerPool) and Requirements for Security in 855 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 856 September 2008, . 858 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 859 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 860 RFC 6376, DOI 10.17487/RFC6376, September 2011, 861 . 863 Appendix A. Test Vectors 865 FIXME: This document should contain examples of well-formed and 866 malformed messages using cryptographic key material and certificates 867 from [I-D.draft-bre-openpgp-samples-01] and 868 [I-D.draft-dkg-lamps-samples-02]. 870 It may also include example renderings of these messages. 872 Author's Address 874 Daniel Kahn Gillmor 875 American Civil Liberties Union 876 125 Broad St. 877 New York, NY, 10004 878 United States of America 880 Email: dkg@fifthhorseman.net