American Civil Liberties Union

125 Broad St. New York, NY 10004 USA dkg@fifthhorseman.net

int lamps Internet-Draft End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common failures.

Introduction E-mail end-to-end security using S/MIME and PGP/MIME cryptographic standards can provide integrity, authentication and confidentiality to MIME e-mail messages . However, there are many ways that a receiving mail user agent can misinterpret or accidentally break these security guarantees (e.g., ). A mail user agent that interprets a message with end-to-end cryptographic protections needs to do so defensively, staying alert to different ways that these protections can be bypassed by mangling (either malicious or accidental) or a failed user experience. A mail user agent that generates a message with end-to-end cryptographic protections should be aware of these defensive interpretation strategies, and should compose any new outbound message conservatively if they want the protections to remain intact.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 ( and ) when, and only when, they appear in all capitals, as shown here.

Terminology For the purposes of this document, we define the following concepts:

• MUA is short for Mail User Agent; an e-mail client.
• Protection of message data refers to cryptographic encryption and/or signatures, providing confidentiality, authenticity, and/or integrity.
• Cryptographic Layer, Cryptographic Envelope, Cryptographic Payload, and Errant Cryptographic Layer are defined in
• A well-formed e-mail message with cryptographic protection has both a Cryptographic Envelope and a Cryptographic Payload,
• Structural Headers are documented in .

Structural Headers A message header whose name begins with Content- is referred to in this document as a "structural" header. These headers indicate something about the specific MIME part they are attached to, and cannot be transferred or copied to other parts without endangering the readability of the message. This includes (but is not limited to):

• Content-Type
• Content-Transfer-Encoding
• Content-Disposition

FIXME: are there any non-Content-* headers we should consider as structural?

Usability The end user (the operator of the MUA) is unlikely to understand complex end-to-end cryptographic protections on any e-mail message, so keep it simple. For clarity to the user, any cryptographic protections should apply to the message as a whole, not just to some subparts. This is true for message composition: the standard message composition user interface of an MUA should offer minimal controls which indicate which types of protection to apply to the new message as a whole. This is also true for message interpretation: the standard message rendering user interface of an MUA should offer a minimal, clear indicator about the end-to-end cryptographic status of the message as a whole.

Types of Protection A given message might be:

• signed,
• encrypted, or
• both signed and encrypted.

Given that many e-mail messages offer no cryptographic protections, the user needs to be able to detect which protections are present for any given message.

Cryptographic MIME Message Structure Implementations use the structure of an e-mail message to protect the headers. This section establishes some conventions about how to think about message structure.

Cryptographic Layers "Cryptographic Layer" refers to a MIME substructure that supplies some cryptographic protections to an internal MIME subtree. The internal subtree is known as the "protected part" though of course it may itself be a multipart object. In the diagrams below, ↧ indicates "decrypts to", and ⇩ indicates "unwraps to".

S/MIME Cryptographic Layers For S/MIME , there are four forms of Cryptographic Layers: multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 authEnveloped-data.

S/MIME Multipart Signed Cryptographic Layer This MIME layer offers authentication and integrity.

S/MIME PKCS7 signed-data Cryptographic Layer This MIME layer offers authentication and integrity.

S/MIME PKCS7 enveloped-data Cryptographic Layer This MIME layer offers confidentiality.

S/MIME PKCS7 authEnveloped-data Cryptographic Layer This MIME layer offers confidentiality and integrity. Note that enveloped-data () and authEnveloped-data () have identical message structure and semantics. The only difference between the two is ciphertext malleability. The examples in this document only include enveloped-data, but the implications for that layer apply to authEnveloped-data as well.

PKCS7 Compression is NOT a Cryptographic Layer The Cryptographic Message Syntax (CMS) provides a MIME compression layer (smime-type="compressed-data"), as defined in . While the compression layer is technically a part of CMS, it is not considered a Cryptographic Layer for the purposes of this document.

PGP/MIME Cryptographic Layers For PGP/MIME there are two forms of Cryptographic Layers, signing and encryption.

PGP/MIME Signing Cryptographic Layer (multipart/signed) This MIME layer offers authenticity and integrity.

PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) Note that for PGP/MIME, this MIME layer can offer any of:

• confidentiality (via a Symmetrically Encrypted Data Packet, see Section 5.7 of ; a MUA MUST NOT generate this form due to ciphertext malleability)
• confidentiality and integrity (via a Symmetrically Encrypted Integrity Protected Data Packet (SEIPD), see section 5.13 of ), or
• confidentiality, integrity, and authenticity all together (by including an OpenPGP Signature Packet within the SEIPD).

Cryptographic Envelope The Cryptographic Envelope is the largest contiguous set of Cryptographic Layers of an e-mail message starting with the outermost MIME type (that is, with the Content-Type of the message itself). If the Content-Type of the message itself is not a Cryptographic Layer, then the message has no cryptographic envelope. "Contiguous" in the definition above indicates that if a Cryptographic Layer is the protected part of another Cryptographic Layer, the layers together comprise a single Cryptographic Envelope. Note that if a non-Cryptographic Layer intervenes, all Cryptographic Layers within the non-Cryptographic Layer are not part of the Cryptographic Envelope. They are Errant Cryptographic Layers (see ). Note also that the ordering of the Cryptographic Layers implies different cryptographic properties. A signed-then-encrypted message is different than an encrypted-then-signed message. See .

Cryptographic Payload The Cryptographic Payload of a message is the first non-Cryptographic Layer - the "protected part" - within the Cryptographic Envelope.

Types of Cryptographic Envelope

Simple Cryptographic Envelopes As described above, if the "protected part" identified in the sction above is not itself a Cryptographic Layer, that part is the Cryptographic Payload. If the application wants to generate a message that is both encrypted and signed, it MAY use the simple MIME structure from by ensuring that the Encrypted Message within the application/octet-stream part contains an Signed Message (the final option described in .

Multilayer Cryptographic Envelopes It is possible to construct a Cryptographic Envelope consisting of multiple layers with either S/MIME or PGP/MIME , for example using the following structure: When handling such a message, the properties of the Cryptographic Envelope are derived from the series A, C. As noted in , PGP/MIME applications also have a simpler MIME construction available with the same cryptographic properties.

Errant Crytptographic Layers Due to confusion, malice, or well-intentioned tampering, a message may contain a Cryptographic Layer that is not part of the Cryptographic Envelope. Such a layer is an Errant Cryptographic Layer. An Errant Cryptographic Layer SHOULD NOT contribute to the message's overall cryptographic state. Guidance for dealing with Errant Cryptographic Layers can be found in .

Mailing List Wrapping Some mailing list software will re-wrap a well-formed signed message before re-sending to add a footer, resulting in the following structure seen by recipients of the e-mail: In this message, L is the footer added by the mailing list. I is now an Errant Cryptographic Layer. Note that this message has no Cryptographic Envelope at all. It is NOT RECOMMENDED to produce e-mail messages with this structure, because the data in part L may appear to the user as though it were part of J, though they have different cryptographic properties. In particular, if the user believes that the message is signed, but cannot distinguish L from J then the author of L can effectively tamper with content of the signed message, breaking the user's expectation of integrity and authenticity.

A Baroque Example Consider a message with the following overcomplicated structure: The 3 Cryptographic Layers in such a message are rooted in parts M, Q, and S. But the Cryptographic Envelope of the message consists only of the properties derived from the series M, Q. The Cryptographic Payload of the message is part R. Part S is an Errant Cryptographic Layer. Note that this message has both a Cryptographic Envelope and an Errant Cryptographic Layer. It is NOT RECOMMENDED to generate messages with such complicated structures. Even if a receiving MUA can parse this structure properly, it is nearly impossible to render in a way that the user can reason about the cryptographic properties of part T compared to part V.

Message Composition This section describes the ideal composition of an e-mail message with end-to-end cryptographic protection. A message composed with this form is most likely to achieve its end-to-end security goals.

Message Composition Algorithm This section roughly describes the steps that a MUA should use to compose a cryptographically-protected message that has a proper cryptographic envelope and payload. The message composition algorithm takes three parameters:

• origbody: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has structural headers present (see ).
• origheaders: the intended non-structural headers for the message, represented here as a table mapping from header names to header values.. For example, origheaders['From'] refers to the value of the From header that the composing MUA would typically place on the message before sending it.
• crypto: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.

The algorithm returns a MIME object that is ready to be injected into the mail system:

• Apply crypto to origbody, yielding MIME tree output
• For header name h in origheaders:
  • Set header h of output to origheaders[h]
• Return output

Encryption Outside, Signature Inside Users expect any message that is both signed and encrypted to be signed inside the encryption, and not the other way around. Putting the signature inside the encryption has two advantages:

• The details of the signature remain confidential, visible only to the parties capable of decryption.
• Any mail transport agent that modifies the message is unlikely to be able to accidentally break the signature.

A MUA SHOULD NOT generate an encrypted and signed message where the only signature is outside the encryption.

Avoid Offering Encrypted-only Messages When generating an e-mail, the user has options about what forms of end-to-end cryptographic protections to apply to it. In some cases, offering any end-to-end cryptographic protection is harmful: it may confuse the recipient and offer no benefit. In other cases, signing a message is useful (authenticity and integrity are desirable) but encryption is either impossible (for example, if the sender does not know how to encrypt to all recipients) or meaningless (for example, an e-mail message to a mailing list that is intended to be be published to a public archive). In other cases, full end-to-end confidentiality, authenticity, and integrity are desirable. It is unclear what the use case is for an e-mail message with end-to-end confidentiality but without authenticity or integrity. A reasonable MUA will keep its message composition interface simple, so when presenting the user with a choice of cryptographic protection, it SHOULD offer no more than three choices:

• no end-to-end cryptographic protection
• signing-only
• signed and encrypted

Composing a Reply Message When replying to a message, most MUAs compose an initial draft of the reply that contains quoted text from the original message. A responsible MUA will take precautions to avoid leaking the cleartext of an encrypted message in such a reply. If the original message was end-to-end encrypted, the replying MUA MUST either:

• compose the reply with end-to-end encryption, or
• avoid including quoted text from the original message.

In general, MUAs SHOULD prefer the first option: to compose an encrypted reply. This is what users expect. However, in some circumstances, the replying MUA cannot compose an encrypted reply. For example, the MUA might not have a valid, unexpired, encryption-capable certificate for all recipients. This can also happen during composition when a user adds a new recipient into the reply, or manually toggles the cryptographic protections to remove encryption. In this circumstance, the composing MUA SHOULD strip the quoted text from the original message. Note additional nuance about replies to malformed messages that contain encryption in .

Message Interpretation Despite the best efforts of well-intentioned senders to create e-mail messages with well-formed end-to-end cryptographic protection, receiving MUAs will inevitably encounter some messages with malformed end-to-end cryptographic protection. This section offers guidance on dealing with both well-formed and malformed messages containing Cryptographic Layers.

Rendering Well-formed Messages A message is well-formed when it has a Cryptographic Envelope, a Cryptographic Payload, and no Errant Cryptographic Layers. Rendering a well-formed message is straightforward. The receiving MUA should evaluate and summarize the cryptographic properties of the Cryptographic Envelope, and display that status to the user in a secure, strictly-controlled part of the UI. In particular, the part of the UI used to render the cryptographic summary of the message MUST NOT be spoofable, modifiable, or otherwise controllable by the received message itself. 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.

Errant Cryptographic Layers If an incoming message has any Errant Cryptographic Layers, the interpreting MUA SHOULD ignore those layers when rendering the cryptographic summary of the message to the user.

Errant Signing Layer When rendering a message with an Errant Cryptographic Layer that provides authenticity and integrity (via signatures), the message should be rendered by replacing the Cryptographic layer with the part it encloses. For example, a message with this structure: Should be rendered identically to this: In such a situation, an MUA SHOULD NOT indicate in the cryptographic summary that the message is signed.

Exception: Mailing List Footers The use case described in is common enough in some contexts, that a MUA MAY decide to handle it as a special exception. If the MUA determines that the message comes from a mailing list (it has a List-ID header), and it has a structure that appends a footer to a signing-only Cryptographic Layer with a valid signature, such as: or: Then, the MUA MAY indicate to the user that this is a signed message that has been wrapped by the mailing list. In this case, the MUA MUST distinguish the footer (part L) from the protected part (part J) when rendering any information about the signature. One way to do this is to offer the user two different views of the message: the "mailing list" view, which hides any cryptographic summary but shows the footer: or the "sender's view", which shows the cryptographic summary but hides the footer:

Errant Encryption Layer An MUA may encounter a message with an Errant Cryptographic Layer that offers confidentiality (encryption), and the MUA is capable of decrypting it. The user wants to be able to see the contents of any message that they receive, so an MUA in this situation SHOULD decrypt the part. In this case, though, the MUA MUST NOT indicate in the message's cryptographic summary that the message itself was encrypted. Such an indication could be taken to mean that other (non-encrypted) parts of the message arrived with cryptographic confidentiality.

Replying to a Message with an Errant Encryption Layer Note that there is an asymmetry here between rendering and replying to a message with an Errant Encryption Layer. When rendering, the MUA does not indicate that the message was encrypted, even if some subpart of it was decrypted for rendering. But when composing a reply that contains quoted text from the decrypted subpart, the reply message SHOULD be marked for encryption, as noted in {#composing-reply}. Alternately, if the reply message cannot be encrypted (or if the user elects to not encrypt the reply), the composed reply MUST NOT include any material from the decrypted subpart.

Forwarded Messages with Cryptographic Protection An incoming e-mail message may include an attached forwarded message, typically as a MIME subpart with Content-Type: message/rfc822 () or Content-Type: message/global (). Regardless of the cryptographic protections and structure of the incoming message, the internal forwarded message may have its own Cryptographic Envelope. The Cryptographic Layers that are part of the Cryptographic Envelope of the forwarded message are not Errant Cryptographic Layers of the surrounding message - they are simply layers that apply to the forwarded message itself. The rendering MUA MUST NOT conflate the cryptographic protections of the forwarded message with the cryptographic protections of the incoming message. The rendering MUA MAY render a cryptograpic summary of the protections afforded to the forwarded message by its own Cryptographic Envelope, as long as that rendering is unambiguously tied to the forwarded message itself.

Signature failures A cryptographic signature may fail in multiple ways. A receiving MUA that discovers a failed signature should treat the message as though the signature did not exist. This is similar to the standard guidance for about failed DKIM signatures (see section 6.1 of ). A MUA SHOULD NOT render a message with a failed signature as more dangerous or more dubious than a comparable message without any signature at all. A MUA that encounters an encrypted-and-signed message where the signature is invalid SHOULD treat the message the same way that it would treat a message that is encryption-only. Some different ways that a signature may be invalid on a given message:

• the signature is not cryptographically valid (the math fails).
• the signature relies on suspect cryptographic primitives (e.g. over a legacy digest algorithm, or was made by a weak key, e.g., 1024-bit R.SA)
• the signature is made by a certificate which the receiving MUA does not have access to.
• the certificate that made the signature was revoked.
• the certificate that made the signature was expired at the time that the signature was made.
• the certificate that made the signature does not correspond to the author of the message.
• the signature indicates that it was made at a time much before or much after from the date of the message itself.

A valid signature must pass all these tests, but of course invalid signatures may be invalid in more than one of the ways listed above.

Common Pitfalls and Guidelines This section highlights a few "pitfalls" and guidelines based on these discussions and lessons learned. FIXME: some possible additional commentary on:

• indexing and search of encrypted messages
• managing access to cryptographic secret keys that require user interaction
• secure deletion
• inline PGP, ugh

IANA Considerations MAYBE: provide an indicator in the IANA header registry for which headers are "structural" ? This is probably unnecessary.

Security Considerations This entire document addresses security considerations about end-to-end cryptographic protections for e-mail messages.

Document Considerations [ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the author. Please direct all significant commentary to the public IETF LAMPS mailing list: spasm@ietf.org

Document History

Acknowledgements The set of constructs and recommendations in this document are derived from discussions with many different implementers, including Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David Bremner, Holger Krekel, Jameson Rollins, juga, Patrick Brunschwig, and Vincent Breitmoser.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Informative References n.d. The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK] This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]

Test Vectors FIXME: This document should contain examples of well-formed and malformed messages using cryptographic key material and certificates from and . It may also include example renderings of these messages.