SMTP Require TLS Option
RFC 8689

Document Type RFC - Proposed Standard (November 2019; No errata)
Last updated 2019-11-27
Replaces draft-fenton-smtp-require-tls
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Valery Smyslov
Shepherd write-up Show (last changed 2018-12-05)
IESG IESG state RFC 8689 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Alexey Melnikov
Send notices to Valery Smyslov <valery@smyslov.net>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                         J. Fenton
Request for Comments: 8689                              Altmode Networks
Category: Standards Track                                  November 2019
ISSN: 2070-1721

                        SMTP Require TLS Option

Abstract

   The SMTP STARTTLS option, used in negotiating transport-level
   encryption of SMTP connections, is not as useful from a security
   standpoint as it might be because of its opportunistic nature;
   message delivery is, by default, prioritized over security.  This
   document describes an SMTP service extension, REQUIRETLS, and a
   message header field, TLS-Required.  If the REQUIRETLS option or TLS-
   Required message header field is used when sending a message, it
   asserts a request on the part of the message sender to override the
   default negotiation of TLS, either by requiring that TLS be
   negotiated when the message is relayed or by requesting that
   recipient-side policy mechanisms such as MTA-STS and DNS-Based
   Authentication of Named Entities (DANE) be ignored when relaying a
   message for which security is unimportant.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8689.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  The REQUIRETLS Service Extension
   3.  The TLS-Required Header Field
   4.  REQUIRETLS Semantics
     4.1.  REQUIRETLS Receipt Requirements
     4.2.  REQUIRETLS Sender Requirements
       4.2.1.  Sending with TLS Required
       4.2.2.  Sending with TLS Optional
     4.3.  REQUIRETLS Submission
     4.4.  Delivery of REQUIRETLS messages
   5.  Non-delivery Message Handling
   6.  Reorigination Considerations
   7.  IANA Considerations
   8.  Security Considerations
     8.1.  Passive Attacks
     8.2.  Active Attacks
     8.3.  Bad-Actor MTAs
     8.4.  Policy Conflicts
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Examples
     A.1.  REQUIRETLS SMTP Option
     A.2.  TLS-Required Header Field
   Acknowledgements
   Author's Address

1.  Introduction

   The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a
   means by which an SMTP server and client can establish a Transport
   Layer Security (TLS) protected session for the transmission of email
   messages.  By default, TLS is used only upon mutual agreement
   (successful negotiation) of STARTTLS between the client and server;
   if this is not possible, the message is sent without transport
   encryption.  Furthermore, it is common practice for the client to
   negotiate TLS even if the SMTP server's certificate is invalid.

   Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may
   impose requirements for the use of TLS for email destined for some
   domains.  However, such policies do not allow the sender to specify
   which messages are more sensitive and require transport-level
   encryption and which ones are less sensitive and ought to be relayed
   even if TLS cannot be negotiated successfully.

   The default opportunistic nature of SMTP TLS enables several on-the-
   wire attacks on SMTP security between MTAs.  These include passive
   eavesdropping on connections for which TLS is not used, interference
   in the SMTP protocol to prevent TLS from being negotiated (presumably
   accompanied by eavesdropping), and insertion of a man-in-the-middle
   attacker exploiting the lack of server authentication by the client.
   Attacks are described in more detail in the Security Considerations
   section of this document.

   REQUIRETLS consists of two mechanisms: an SMTP service extension and
   a message header field.  The service extension is used to specify
   that a given message sent during a particular session MUST be sent
Show full document text