Dispatch J.C. Klensin Internet-Draft 1 July 2026 Intended status: Informational Expires: 2 January 2027 Confidentiality and Authenticity Protection for Internet Email draft-klensin-email-tls-applicability-00 Abstract IETF review of an Applicability Statement for the core email protocols exposed considerable confusion about the applicability and effectiveness of various techniques for authenticating email and keeping messages and their various elements confidential. Equally or more important, there is confusion about the relationships among various possible methods and tools, with the documents of those methods, taken one at a time, often failing to address those relationships and the tradeoffs involved explicitly. This document describes the various approaches with their strengths and weaknesses, and provides advice about best practices under different conditions. Role of this draft This initial draft is a outline intended to help identify the topic area. It does not provide any specific answers or details and the list of topics in subject headings and elsewhere is not intended to be either complete or definitive. It also omits most specific references. 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/. 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 2 January 2027. Klensin Expires 2 January 2027 [Page 1] Internet-Draft Email Confidentiality and Authenticity July 2026 Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Balance, absolutes, and tradeoffs . . . . . . . . . . . . . . 4 2.1. Deliverability . . . . . . . . . . . . . . . . . . . . . 4 2.2. Confidentiality Questions -- What should be protected? . 4 2.3. Authentication Questions -- How confident do we need to be? . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ...Temporary note . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocols to protect link level -- single hops . . . . . . . 5 4.1. SMTP Extensions . . . . . . . . . . . . . . . . . . . . . 5 4.2. Protocols requiring SMTP-senders to make DNS checks (other than MX lookups) . . . . . . . . . . . . . . . . . . . . 5 4.3. Confidential Transport . . . . . . . . . . . . . . . . . 5 5. Message Content Protection and Authentication . . . . . . . . 5 6. Regulatory Possibilities and Constraints . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the current global Internet, questions of how to keep messages confidential and to authenticate the various human and computer actors can become quite complex just because the environments through which messages pass are extremely varied. For example, if a message originates in a web browser connecting to a large email provider and is destined for a different customer of that provider, conditions and considerations are quite different from when a message originates in a (non-web) Mail User Agent (MUA) on a well-protected LAN, is Klensin Expires 2 January 2027 [Page 2] Internet-Draft Email Confidentiality and Authenticity July 2026 transferred to a Submission Server (see RFC 6409) at the boundary between that LAN and the more accessible public Internet. The message is then, using SMTP, transferred via servers providing one or more store and forward steps before reaching the destination server. After delivery to that server, the message is handled locally and then possibly accessed via a different MUA on a different protected LAN. Messages that must traverse delay-tolerant paths pose other challenges and may require other (or modified) tools or acceptance of some risk that would not be acceptable in other scenarios. IETF review of an Applicability Statement for the core email protocols [draft-ietf-emailcore-as] exposed considerable confusion about the applicability and effectiveness of various techniques for authenticating email and keeping messages and their various elements confidential. Equally or more important, there is confusion about the relationships among various possible methods and tools, with the documents specifying those methods, taken one at a time, often failing to explicitly address those relationships and the tradeoffs involved. Message submission, which is critical to some email transmission scenarios, including some of those suggested above, is not considered a "core email protocol" and was consequently out of scope for the EMAILCORE WG. As a result, that Applicability Statement also fails to address cases in which the utility and behavior of various security-related tools differs between message submission and SMTP contexts. // Note in draft: This effort is not intended to criticize the // existing protocols in any way. Instead, the intent is to improve // email security in practice by identifying best strategies and // practices for different situations and suggesting how various // protocols can be used for optimal effect and to avoid interfering // with each other. This document describes the various approaches with their strengths and weaknesses. It also provides advice about best practices under different conditions. // While this paragraph is not needed in this draft of the document, // it is anticipated that later versions will require it. 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 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. Klensin Expires 2 January 2027 [Page 3] Internet-Draft Email Confidentiality and Authenticity July 2026 2. Balance, absolutes, and tradeoffs Much of the material in this section may turn out to be (or require) a mini-tutorial on how email actually works, including differences between highly connected networks and more fragile or deliberately isolated ones. That material is, however, not now generally available in a form addressed to general users or security practitioners rather than email experts. 2.1. Deliverability * How much assurance of confidentiality of messages and their envelopes, sender authenticity, authentication of systems in the store and forward path is required? * If that cannot be achieved, should the message be returned as undeliverable (as SMTP now requires) or dropped? * Who decides and how? 2.2. Confidentiality Questions -- What should be protected? * Message path information * Components of the envelope (note that SMTP Extensions, by definition, expose some information). * Message header section * MIME body part structure * Body part content - message "payload" 2.3. Authentication Questions -- How confident do we need to be? * Message originator * SMTP-senders and SMTP-receivers * Traceability of mail path -- the "Received:" chain and various assertion headers. * Integrity of traditional headers, including recipient names, date, subject. * Integrity (and tamper-resistance) of message content. Klensin Expires 2 January 2027 [Page 4] Internet-Draft Email Confidentiality and Authenticity July 2026 3. ...Temporary note ... for each protocol below, discuss both confidentiality and authentication features -- are any present, what do they cover, and how effective (and attack-resistant) are they? 4. Protocols to protect link level -- single hops 4.1. SMTP Extensions * STARTTLS and REQUIRETLS * SMTP AUTH (is it actually useful for other than Message Submission? How to describe it for the Message Submission and SMTP cases?) * Others? 4.2. Protocols requiring SMTP-senders to make DNS checks (other than MX lookups) * MTA-STS * Others? Possibly including work now being proposed like DKA? 4.3. Confidential Transport * IPSec * Specialized tunnels 5. Message Content Protection and Authentication These techniques are intended be useful from the originating user to (or close to) the receiving one, independent of store and forward effects. * S/MIME * OpenPGP * Traditional codes and coding (non-encryption) * Others? Klensin Expires 2 January 2027 [Page 5] Internet-Draft Email Confidentiality and Authenticity July 2026 6. Regulatory Possibilities and Constraints While these topics are not, strictly speaking, technical issues with email or related security protocols, they can affect the email environment and which measures are feasible and appropriate. Consequently, they can be part of the picture of which protocols are best used, and how they are used, in different environments. * Government access to keys * Regulated servers and mail stores and government access * National boundary gateways * Prohibitions and requirements on national and regional conditions. 7. Acknowledgements .. to be supplied .. 8. IANA Considerations // RFC Editor: Please remove this section before publication. This memo includes no requests to or actions for IANA. 9. Security Considerations This Applicability Statement proposal is intended to lay a foundation for more clearly explaining the options for Confidentiality and Authentication protection for Internet Mail, including the strengths and weaknesses of the various options. 10. References 10.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References Klensin Expires 2 January 2027 [Page 6] Internet-Draft Email Confidentiality and Authenticity July 2026 Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires 2 January 2027 [Page 7]