Internet DRAFT - draft-dkg-mail-cleartext-copy

draft-dkg-mail-cleartext-copy







Network Working Group                                      D. K. Gillmor
Internet-Draft                                          21 February 2023
Intended status: Standards Track                                        
Expires: 25 August 2023


                 Encrypted E-mail with Cleartext Copies
                    draft-dkg-mail-cleartext-copy-01

Abstract

   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.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://dkg.gitlab.io/cleartext-copy/.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-dkg-
   mail-cleartext-copy/.

   Discussion of this document takes place on the Secdispatch Working
   Group mailing list (mailto:secdispatch@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/secdispatch/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/secdispatch/.

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/dkg/cleartext-copy.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.



Gillmor                  Expires 25 August 2023                 [Page 1]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 August 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Simple Three-Party E-mail . . . . . . . . . . . . . . . .   4
     2.2.  Cleartext Remote Drafts Folder  . . . . . . . . . . . . .   4
     2.3.  Cleartext Remote Sent Folder  . . . . . . . . . . . . . .   4
     2.4.  Public Mailing List . . . . . . . . . . . . . . . . . . .   4
     2.5.  Trusted Mailserver  . . . . . . . . . . . . . . . . . . .   4
   3.  Problems  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Reply All . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  User Models . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Explicit Indicator of Cleartext Copy  . . . . . . . . . .   6
       4.1.1.  Cleartext-Copy Header Field . . . . . . . . . . . . .   6
       4.1.2.  Cleartext-Copy-To Header Field  . . . . . . . . . . .   6
       4.1.3.  Encrypted-To Header Field . . . . . . . . . . . . . .   7
     4.2.  Forbid Cleartext Copy . . . . . . . . . . . . . . . . . .   7
     4.3.  Handling an Encrypted Message with a Cleartext Copy . . .   8
   5.  Picking a Solution  . . . . . . . . . . . . . . . . . . . . .   8
   6.  User Experience Considerations  . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.1.  Misrepresentations By Sender are Out of Scope . . . . . .   9
     8.2.  Cryptographic Guarantees  . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9



Gillmor                  Expires 25 August 2023                 [Page 2]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  10
     B.1.  Changes from draft-dkg-mail-cleartext-copy-00 to
           draft-dkg-mail-cleartext-copy-01  . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document is concerned with end-to-end encrypted e-mail messages,
   regardless of the type of encryption used.  Both S/MIME ([RFC8551]
   and PGP/MIME ([RFC3156]) 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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.1.  Terminology

   In this draft:

   *  MUA is short for Mail User Agent; an e-mail client.

2.  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.






Gillmor                  Expires 25 August 2023                 [Page 3]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


   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.

2.1.  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.

2.2.  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.

2.3.  Cleartext Remote Sent Folder

   Unlike in Section 2.2, 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.

2.4.  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.

2.5.  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.







Gillmor                  Expires 25 August 2023                 [Page 4]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


3.  Problems

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

3.1.  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 [I-D.ietf-lamps-e2e-mail-guidance]).

   In scenarios where a recipient of the message cannot receive
   encrypted mail (e.g. the public mailing list example in Section 2.4),
   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.

3.2.  User Models

   User experience of end-to-end encrypted e-mail is notoriously poor.
   A system that just silently encrypts as aggressively as possible
   might well produce more messages that are unreadable to any
   intervening transport agents.  And, done right, it might even avoid
   creating messages that are unreadable by the intended recipient.

   However, such an opportunistic model is not the end goal of a system
   of end-to-end encryption.  An end-to-end encrypted system typically
   involves a some sort of user expectation (see Section 4 of
   [I-D.knodel-e2ee-definition]).  In a legacy system like e-mail, where
   many messages will not be end-to-end encrypted, satisfying the user
   expectation requires that the user have a clear understanding of what
   specifically is end-to-end encrypted.

   When a user receives an encrypted message that is also posted in the
   clear to a publicly-visible archive (as in Section 2.4), that
   violates most user expectations of end-to-end encryption.






Gillmor                  Expires 25 August 2023                 [Page 5]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


4.  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.

4.1.  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 Section 4.3.

   The proposals here use e-mail headers, so see also Section 8.2 for
   security considerations.

4.1.1.  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?

4.1.2.  Cleartext-Copy-To Header Field

   This document could specify a new e-mail header field with the name
   Cleartext-Copy-To.



Gillmor                  Expires 25 August 2023                 [Page 6]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


   This header field's value is defined to be an address-list, as
   specified in [RFC5322].

   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 Section 2.2) or Sent (see Section 2.3) folder should populate
   this field to indicate to the recipient that a cleartext copy was
   sent to the IMAP server.

4.1.3.  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 [RFC5322].

   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 Section 2.2) or Sent (see Section 2.3) 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?

4.2.  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.



Gillmor                  Expires 25 August 2023                 [Page 7]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


4.3.  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?

5.  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

   *  additional information leakage

   *  risk of user confusion (complexity of user mental models)

6.  User Experience Considerations

   As noted in [I-D.ietf-lamps-e2e-mail-guidance], 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
   [I-D.knodel-e2ee-definition]).

   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?

7.  IANA Considerations

   For example, if we go with Section 4.1.1:





Gillmor                  Expires 25 August 2023                 [Page 8]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


   The IANA registry of Message Headers
   (https://www.iana.org/assignments/message-headers/message-
   headers.xhtml) 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.

8.  Security Considerations

8.1.  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.

8.2.  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
   [I-D.ietf-lamps-header-protection].

   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.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.



Gillmor                  Expires 25 August 2023                 [Page 9]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

9.2.  Informative References

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156,
              DOI 10.17487/RFC3156, August 2001,
              <https://www.rfc-editor.org/rfc/rfc3156>.

   [I-D.ietf-lamps-e2e-mail-guidance]
              Gillmor, D. K., "Guidance on End-to-End E-mail Security",
              Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-
              mail-guidance-05, 6 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              e2e-mail-guidance-05>.

   [I-D.knodel-e2ee-definition]
              Knodel, M., Celi, S., Kolkman, O., and G. Grover,
              "Definition of End-to-end Encryption", Work in Progress,
              Internet-Draft, draft-knodel-e2ee-definition-08, 6
              February 2023, <https://datatracker.ietf.org/doc/html/
              draft-knodel-e2ee-definition-08>.

   [I-D.ietf-lamps-header-protection]
              Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
              Protection for S/MIME", Work in Progress, Internet-Draft,
              draft-ietf-lamps-header-protection-11, 24 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              header-protection-11>.

Appendix A.  Acknowledgements

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

Appendix B.  Document History




Gillmor                  Expires 25 August 2023                [Page 10]

Internet-Draft   Encrypted E-mail with Cleartext Copies    February 2023


B.1.  Changes from draft-dkg-mail-cleartext-copy-00 to draft-dkg-mail-
      cleartext-copy-01

   Added some discussion about user expectations.

Author's Address

   Daniel Kahn Gillmor
   Email: dkg@fifthhorseman.net










































Gillmor                  Expires 25 August 2023                [Page 11]