]>

dkg@fifthhorseman.net

sec Network Working Group Internet-Draft When an e-mail program generates an encrypted message to multiple recipients, it is possible that it has no encryption capability for at least one of the recipients. In this circumstance, an e-mail program may choose to send the message in cleartext to the recipient it cannot encrypt to. This draft currently offers several possible approaches when such a choice is made by the sender, so that the recipient can reason about and act on the cryptographic status of the message responsibly. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secdispatch Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document is concerned with end-to-end encrypted e-mail messages, regardless of the type of encryption used. Both S/MIME ( and PGP/MIME () standards support the creation and consumption of end-to-end encrypted e-mail messages. The goal of this document is to enable a receiving MUA to have solid, reliable behavior and security indicators based on the status of any particular received message, in particular when the sender of the message may have emitted a cleartext copy. The document currently does not pick a single mechanism, as it is more of a survey/problem statement. The final document should select at most a single mechanism with a clear default behavior. 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 when, and only when, they appear in all capitals, as shown here.

Terminology In this draft: MUA is short for Mail User Agent; an e-mail client.

Scenarios The following scenarios are examples where an encrypted message might be produced but some copies of the message are sent or stored in the clear. In all scenarios, Alice is composing a new message to Bob and at least one other copy is generated. Alice has a cryptographic key for Bob, and knows that Bob is capable of decrypting e-mail messages. In each of the following scenarios, Alice's MUA generates an e-mail, and knows that there is at least one cleartext copy of the message stored on a system not under Alice's personal control.

Simple Three-Party E-mail Alice sends a message to Bob and Carol, but Alice has no encryption-capable key for Carol. She encrypts the copy to Bob, but sends a cleartext copy to Carol.

Cleartext Remote Drafts Folder Alice's MUA stores all draft copies of any message she writes in the clear in a Drafts folder, and that folder is itself stored on an IMAP server. When she composes a message, the IMAP server has a cleartext copy of the draft, up until and including when she clicks "Send". Her MUA instructs the IMAP server to delete the draft version of the message, but it also knows that it had at one point a cleartext copy, and cleartext might persist forever.

Cleartext Remote Sent Folder Unlike in , copies of messages sent to Alice's draft folder are encrypted or only stored locally. But when sending an e-mail message to Bob, her MUA generates a cleartext copy an places it in her Sent folder, which is also stored on IMAP.

Public Mailing List Alice "Replies All" to message from Bob on a public mailing list. The public mailing list has on encryption-capable public key (it is archived publicly in the clear), so Alice cannot encrypt to it. But Alice's MUA is configured to opportunistically encrypt every copy possible, so the copy to Bob is encrypted.

Trusted Mailserver Alice and Bob work in different organizations, and Alice's MUA has a policy of encrypting to outside peers that does not apply to members of her own organization. Alice's co-worker David is in Cc on the message, and Alice and David both share a trusted mail server, so Alice does not feel the need to encrypt to Carol. But she wants to defend against the possibility that Bob's mail server could read the contents of her message.

Problems Receiving MUA often needs to behave differently when handling a message with a different cryptographic status.

Reply All The most visible responsibility of an MUA that receives an encrypted message is to avoid leaking the contents of the message in the clear during a reply (see ). In scenarios where a recipient of the message cannot receive encrypted mail (e.g. the public mailing list example in ), a "Reply all" message is unlikely to be an act of effective communication. In the example from that section, if Bob receives an encrypted copy of Alice's message, and he also chooses to "Reply All" to it, his MUA will either: generate a cleartext copy to the mailing list, thereby leaking the contents of what appears to be an encrypted message, or send the mailing list a message encrypted only to Alice, which the rest of the mailing list cannot read. Neither outcome is satisfactory.

Solutions This document has not yet reached consensus on what the right solution is. Two major classes of possible solution are: A message that was generated with a cleartext copy can explicitly indicate that such a cleartext copy exists, which allows the recipient to reason about it differently than a normal end-to-end encrypted message. Forbid MUAs from generating a cleartext copy.

Explicit Indicator of Cleartext Copy It seems plausible that a MUA generating an end-to-end encrypted e-mail message with a cleartext copy could indicate to its recipients that a cleartext copy was also generated. Each recipient could then reason about it differently, as compared to an end-to-end-encrypted e-mail message without a cleartext copy. For example, a recipient doing "reply all" to such an encrypted message could take a different strategy and permit re-sending cleartext copies. For more discussion about how to use such an indicator, see . The proposals here use e-mail headers, so see also for security considerations.

Cleartext-Copy Header Field This document could specify a new e-mail header field with the name Cleartext-Copy. The only defined values of this field are 0 and 1. A MUA that creates an encrypted message with a cleartext copy MUST add this header field with a value of 1 to each encrypted copy of the message. By default, any end-to-end encrypted message that does not have this header field is presumed to have the field with a value of 0 -- meaning that no cleartext copies made by the sending MUA. FIXME: what if the default was 1 instead of defaulting to 0?

Cleartext-Copy-To Header Field This document could specify a new e-mail header field with the name Cleartext-Copy-To. This header field's value is defined to be an address-list, as specified in . A MUA that creates an encrypted message with a cleartext copy to any recipient MUST add this header field to each encrypted copy of the message. The contents of the field are the list of e-mail addresses that were sent cleartext copies of the message. By default, any end-to-end encrypted message that does not have this header field, or that has it with empty contents, is presumed to have no cleartext copies made by the sending MUA. FIXME: it is unclear how a MUA that uses a cleartext remote Drafts (see ) or Sent (see ) folder should populate this field to indicate to the recipient that a cleartext copy was sent to the IMAP server.

Encrypted-To Header Field This document could specify a new e-mail header field with the name Encrypted-To. This header field's value is defined to be an address-list, as specified in . A MUA that creates any encrypted message includes the full address-list of all recipients in To or Cc that it was able to successfully encrypt the message to. The recipient of an encrypted message can then infer based on the contents of this header whether an additional cleartext copy was generated. FIXME: it is unclear how a MUA that uses a cleartext remote Drafts (see ) or Sent (see ) folder should populate this field to indicate to the recipient that a cleartext copy was sent to the IMAP server. FIXME: if the recipient receives an encrypted copy of a message without this header in it, they know that the sender does not support this mechanism. What should be the default assumption in that case: cleartext copy or no cleartext copy?

Forbid Cleartext Copy Another approach would simply be to declare that a MUA that generates an end-to-end encrypted e-mail message MUST NOT store or transmit a cleartext copy.

Handling an Encrypted Message with a Cleartext Copy When one of the copies of the message is known to be sent or stored in clear, a MUA might treat "Reply All" differently. For example, it might be willing to send an additional cleartext copy to some of the recipients. FIXME: what other behaviors might need changing?

Picking a Solution This draft currently does not choose a specific solution, but it should not be published as a final document without choosing at most one solution. Factors to consider when choosing a solution among those presented include: complexity of implementation for senders complexity of implementation for receivers minimizing information leakage

User Experience Considerations As noted in , representing the cryptographic status of a message is challenging even under good circumstances. This is because storing a cleartext copy with a third party breaks most expectations of "end-to-end encryption" (see ). When a single message has multiple cryptographic statuses depending on which copy of the message is being examined, it is even more challenging to represent the cryptographic status of any particular copy of the message. Aside from changing its behavior around Reply All, how should an MUA treat such a message?

IANA Considerations For example, if we go with : The IANA registry of Message Headers should be updated to add a row with Header Field Name Cleartext-Copy , no template, protocol mail, status standard, and a reference to this document.

Security Considerations

Misrepresentations By Sender are Out of Scope This document describes security considerations between mutually-cooperating, end-to-end encryption-capable MUAs. Either party could of course leak cleartext contents of any such message either deliberately or by accident. In some cases, such as a Bcc scenario, the sending MUA is deliberately taking action on the sender's behalf that they do not want the (listed) recipient to know about. Indicating to the listed recipient that a Bcced copy was emitted in the clear may violate the sender's expectations about what was done with the message. This specification is not intended to detect fraud, misbehavior, or deliberate misrepresenation from one of the clients.

Cryptographic Guarantees For the proposed solutions that require a header field, that header field itself needs cryptographic protections, or an intervening mail transport agent could inject it to tamper with the apparent cryptographic status of the message. For this reason, any header field involved in this must be provided with header protection, as described in . Additionally, since this is dealing with encrypted messages only, any relevant header field should probably be stripped from the message before sending, to avoid indicating to a mail transport agent that some cleartext copy of the message is available somewhere.

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. 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 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] 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. 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] American Civil Liberties Union 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. CDT Brave Internet Society End-to-end encryption is an application of cryptography mechanisms and properties in communication systems between endpoints. End-to- end encrypted systems are exceptional in providing both security and privacy properties through confidentiality, integrity and authenticity features for users. Improvements to end-to-end encryption strive to maximize the user's security and privacy while balancing usability and availability. Users of end-to-end encrypted communications expect trustworthy providers of secure implementations to respect and protect them. American Civil Liberties Union pEp Foundation Isode Ltd S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.

Acknowledgements The author would like to thank Daniel Huigens and Bart Butler for explaining the circumstances behind this situation.