Confidentiality and Authenticity Protection for Internet Email
draft-klensin-email-tls-applicability-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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/info/rfc8174>.

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]