Using TLS in Applications                                    D. Margolis
Internet-Draft                                                 M. Risher
Intended status: Standards Track                           N. Lidzborski
Expires: January 9, 2017                                       W. Chuang
                                                                 B. Long                             Google, Inc
Expires: June 18, 2017                                   B. Ramakrishnan
                                                             Yahoo!, Inc
                                                              A. Brotman
                                                            Comcast, Inc
                                                                J. Jones
                                                          Microsoft, Inc
                                                               F. Martin
                                                                LinkedIn
                                                               K. Umbach
                                                                M. Laber
                          1&1 Mail & Media Development & Technology GmbH
                                                            July 8,
                                                       December 15, 2016

              SMTP MTA Strict Transport Security
                       draft-ietf-uta-mta-sts-01 (MTA-STS)
                       draft-ietf-uta-mta-sts-02

Abstract

   SMTP MTA-STS Mail Transfer Agent Strict Transport Security (SMTP STS) is a
   mechanism enabling mail service providers to declare their ability to
   receive TLS-secured connections, to declare
   particular methods for certificate validation, connections and an expected validity of
   certificates presented by their MX hosts, and to request that specify whether
   sending SMTP servers report upon and/or should refuse to deliver messages to MX hosts that cannot be delivered securely. do not
   offer TLS with a trusted server certificate.

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 http://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 January 9, June 18, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Related Technologies  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Differences from DANE   3
   3.  Policy Discovery  . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Advantages of SMTP MTA-STS when compared to DANE . .   4
       2.1.2.  Advantages of DANE when compared to SMTP
     3.1.  MTA-STS TXT Records . . . . .   5
   3.  Policy Semantics . . . . . . . . . . . . . .   4
     3.2.  MTA-STS Policies  . . . . . . . . .   5
     3.1.  Formal Definition . . . . . . . . . . .   5
     3.3.  HTTPS Policy Fetching . . . . . . . . .   6
       3.1.1.  TXT Record . . . . . . . . .   6
     3.4.  Policy Selection for Smart Hosts  . . . . . . . . . . . .   6
       3.1.2.  SMTP MTA-STS
   4.  Policy Validation . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Policy Expirations
     4.1.  MX Matching . . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Policy Updates . . .   7
     4.2.  MX Certificate Validation . . . . . . . . . . . . . . . .   8
     3.3.   7
   5.  Policy Discovery & Authentication Application  . . . . . . . . . . . .   8
     3.4.  Policy Validation . . . . . . . . .   7
     5.1.  MX Preference . . . . . . . . . . .   9
     3.5.  Policy Application . . . . . . . . . . .   8
     5.2.  Policy Application Control Flow . . . . . . . .   9
   4.  Failure Reporting . . . . .   8
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations   8
     6.1.  Policy Updates  . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Future Work . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Contributors  . . . . . .  11
   8.  Appendix 1: Validation Pseudocode . . . . . . . . . . . . . .  12
   9. . . . .  10
   10. Appendix 2: 1: Domain Owner STS example record . . . . . . . . .  12
     9.1.  11
     10.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . . .  12
   10.  11
   11. Appendix 3: DEEP Registration Elements 2: Message delivery pseudocode . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   11.
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  URIs . . . . . . . . . . . . . . . . . . . .  15 . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16  14

1.  Introduction

   The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
   hosts to establish secure SMTP sessions over TLS.  In its current
   form, however, it fails to provide (a) message confidentiality --
   because opportunistic STARTTLS is subject to downgrade attacks -- and
   (b) server authenticity -- because negotiate the trust relationship from email
   domain to MTA server identity is not cryptographically validated. use of a TLS channel for secure mail
   transmission.

   While such _opportunistic_ encryption protocols provide a high
   barrier against passive man-in-the-middle traffic interception, any
   attacker who can delete parts of the SMTP session (such as the "250
   STARTTLS" response) or who can redirect the entire SMTP session
   (perhaps by overwriting the resolved MX record of the delivery
   domain) can perform such a downgrade or interception attack. attacks.

   This document defines a mechanism for recipient domains to publish
   policies specifying:

   o  whether MTAs sending mail to this domain can expect TLS support

   o  how MTAs can validate the TLS  expected validity of server certificate certificates presented during
      mail delivery

   o by the expected identity of MXs that handle mail for this domain domain's
      MX hosts

   o  what an implementing sender a conforming client should do with messages when TLS cannot
      be successfully negotiated

   The mechanism described is separated into four logical components:

   1.  policy semantics: whether senders can expect a server for the
       recipient domain to support TLS encryption and how to validate
       the TLS certificate presented

   2.  policy discovery & authentication: how to discover a domain's
       published STS policy and determine the authenticity of that
       policy

   3.  failure report format: a mechanism for informing recipient
       domains about aggregate failure statistics

   4.  failure handling: what sending MTAs should do in the case of
       policy failures

1.1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

   We also define the following terms for further use in this document:

   o  STS Policy: A definition of committment by the expected Policy Domain to support PKIX
      authenticated TLS availability and
      behavior, as well as the desired actions for a given domain when a
      sending MTA encounters different results. the specified MX hosts.

   o  Policy Domain: The domain against for which an STS Policy is defined.
      (For example, when sending mail to "alice@example.com", the policy
      domain is "example.com".)

   o  Policy Authentication: Authentication of the STS policy retrieved
      for a recipient domain by the sender.

2.  Related Technologies

   The DANE TLSA record [RFC7672] is similar, in that DANE is also
   designed to upgrade opportunistic opportunistic, unauthenticated encryption into required
   required, authenticated encryption.  DANE requires DNSSEC [RFC4033]
   for the secure delivery
   of policies; the mechanism described here presents a variant for
   systems not yet supporting DNSSEC.

2.1.  Differences from DANE

   The primary difference between authentication; the mechanism described here and DANE
   is that DANE requires the use of DNSSEC to authenticate DANE TLSA
   records, whereas SMTP STS instead relies on the
   certificate authority (CA)
   system to avoid interception.  (For authorities (CAs) and does not require DNSSEC.  For a
   thorough discussion of this trade-off, see the section _Security_ _Considerations_.)
   _Considerations_.

   In addition, SMTP MTA-STS introduces a mechanism for failure
   reporting and a STS provides an optional report-only mode, enabling offline ("report-only")
   soft deployments and auditing for compliance.

2.1.1.  Advantages of SMTP MTA-STS when compared to DANE detect policy failures.

3.  Policy Discovery

   SMTP MTA-STS offers STS policies are distributed via HTTPS from a "well-known"
   [RFC5785] path served within the following advantages compared to DANE:

   o  Infrastructure: In comparison to DANE, this proposal does not
      require DNSSEC be deployed on either Policy Domain, and their presence
   and current version are indicated by a TXT record at the Policy
   Domain.  These TXT records additionally contain a policy "id" field,
   allowing sending or receiving
      domain.  In addition, the reporting feature of SMTP MTA-STS can be
      deployed to perform offline analysis of STARTTLS failures,
      enabling mail providers MTAs to gain insight into the security of their
      SMTP connections without check the need to modify MTA codebases
      directly.

   o  Offline or report-only usage: DANE does not provide a reporting
      mechanism and does not have a concept currency of "report-only" for
      failures; as a result, a service provider cannot receive metrics
      on TLS acceptability cached policy
   without asking senders to enforce a given
      policy; similarly, senders who cannot enforce DANE constraints at
      send-time have no mechanism to provide recipients such metrics
      from performing an offline (and potentially easier-to-deploy) logs-analysis
      batch process.

2.1.2.  Advantages of DANE when compared to SMTP MTA-STS

   o  Infrastructure: DANE may be easier for some providers to deploy.
      In particular, for providers who already support DNSSEC, SMTP MTA-
      STS would additionally require they host a HTTPS webserver and
      obtain request.

   To discover if a CA-signed X.509 certificate for the recipient domain.

   o  Security: DANE offers an advantage against policy-lookup DoS
      attacks; that is, while a DNSSEC-signed NXDOMAIN response to domain implements MTA-STS, a
      DANE lookup authoritatively indicates the lack of sender need
   only resolve a DANE record,
      such single TXT record.  To see if an option to authenticate updated policy non-existence does not exist
      when looking up is
   available for a policy over plain DNS.

3.  Policy Semantics

   SMTP MTA-STS policies are distributed via domain for which the sender has a "well known" HTTPS
   endpoint in previously cached
   policy, the Policy Domain.  A corresponding sender need only check the TXT record's version "id"
   against the cached value.

3.1.  MTA-STS TXT Records

   The MTA-STS TXT record in is a TXT record with the DNS
   alerts sending MTAs to name "_mta-sts" at
   the presence of a policy file.

   (Future implementations may move to alternate methods of policy
   discovery or distribution.  See Policy Domain.  For the section _Future_ _Work_ for more
   discussion.)

   *The domain "example.com", this record would
   be "_mta-sts.example.com".  MTA-STS TXT record records MUST specify be US-ASCII,
   semicolon-separated key/value pairs containing the following fields:* fields:

   o  "v": (plain-text, required).  Currently only "STSv1" is supported.

   o  "id": (plain-text, required).  A short string used to track policy
      updates.  This string MUST uniquely identify a given instance of a
      policy, such that senders can determine when the policy has been
      updated by comparing to the "id" of a previously seen policy, and
      must also match policy.
      There is no implied ordering of "id" fields between revisions.

   An example TXT record is as below:

   "_mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;""

   The formal definition of the "policy_id" value "_mta-sts" TXT record, defined using
   [RFC5234], is as follows:

      sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B]

      sts-version     = "v" *WSP "=" *WSP %x53 %x54        ; "STSv1"
                        %x53 %x76 %x31

      sts-id          = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)

   If multiple TXT records for "_mta-sts" are returned by the resolver,
   records which do not begin with "v=STSv1;" are discarded.  If the
   number of resulting records is not one, senders MUST assume the distributed policy.

   A lenient parser SHOULD accept a
   recipient domain does not implement MTA STS and skip the remaining
   steps of policy file implementing discovery.

3.2.  MTA-STS Policies

   The policy itself is a superset JSON [RFC4627] object served via the HTTPS GET
   method from the fixed [RFC5785] "well-known" path of this specification, in which case unknown values SHALL be ignored.

   *Policies MUST specify ".well-known/
   mta-sts.json" served by the "mta-sts" host at the Policy Domain.
   Thus for "example.com" the path is "https://mta-sts.example.com
   /.well-known/mta-sts.json".

   This JSON object contains the following fields in JSON* [RFC4627]
   *format:* key/value pairs:

   o  "version": (plain-text, required).  Currently only "STSv1" is
      supported.

   o  "mode": (plain-text, required).  If "enforce",  Either "enforce" or "report",
      indicating the receiving expected behavior of a sending MTA
      requests that messages be delivered only if they conform to in the
      STS policy.  If "report" case of a
      policy validation failure.

   o  "max_age": Max lifetime of the receiving MTA requests policy (plain-text non-negative
      integer seconds, required).  Well-behaved clients SHOULD cache a
      policy for up to this value from last policy fetch time.  To
      mitigate the risks of attacks at policy refresh time, it is
      expected that failure
      reports this value typically be delivered, as specified by in the "rua" parameter. range of weeks or
      greater.

   o  "mx": MX patterns (list of plain-text MX match patterns, strings, required).
      One or more comma-separated patterns matching the expected MX for this domain.
      For example, "["*.example.com", "*.example.net"]" indicates that
      mail for this domain might be handled by any MX whose hostname is with a subdomain of hostname at
      "example.com" or "example.net".  The semantics for these  Valid patterns should can be either
      hostname literals (e.g. "mx1.example.com") or wildcard matches, so
      long as the
      ones found in wildcard occupies the "Checking of Wildcard Certificates" rules full left-most label in
      Section 6.4.3 of [RFC6125].

   o  "max_age": Max lifetime of the policy (plain-text integer
      seconds).  Well-behaved clients SHOULD cache a policy for up to
      this value from last policy fetch time.

   o  "policy_id": A short string used to track policy updates.  This
      string MUST uniquely identify a given instance of a policy, such
      that senders can determine when the policy has been updated by
      comparing to the "policy_id" of a previously seen policy.

   A lenient parser SHOULD accept a policy file which
      pattern.  (Thus "*.example.com" is valid JSON
   implementing a superset of this specification, in which case unknown
   values SHALL be ignored.

3.1.  Formal Definition

3.1.1.  TXT Record

   The formal definition of the "_mta_sts" TXT record, defined using
   [RFC5234], but "mx*.example.com" is as follows:

      sts-text-record = sts-version *WSP %x3B *WSP sts-id

      sts-version     = "v" *WSP "=" *WSP %x53 %x54        ; "STSv1"
                        %x53 %x76 %x31

      sts-id          = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)

3.1.2.  SMTP MTA-STS Policy

   The formal definition of the SMTP MTA-STS policy, using [RFC5234],
      not.)

   An example JSON policy is as follows:

sts-record      = WSP %x7B WSP  ; below:

                      { left curly bracket
                  sts-element   ; comma-separated
                  [             ; list
                  WSP %x2c WSP  ; of
                  sts-element   ; sts-elements
                  ]
                  WSP %x7d WSP  ; } right curly bracket

sts-element     = sts-version / sts-mode / sts-id / sts-mx / sts-max_age

sts-version     = %x22 "version" %x22 *WSP %x3a *WSP ;
                        "version":
                  %x22 %x53 %x54 %x53 %x76 %x31      ; "STSv1"

sts-mode        = %x22 "mode" %x22 *WSP %x3a *WSP    ; "STSv1",
                        "mode":
                  %x22 ("report" / "enforce") %x22   ; "report"/"enforce"

sts-id          = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id":
                  %x22 1*32(ALPHA / DIGIT) %x22        ; some chars

sts-mx          = %x22 "mx" $x22 *WSP %x3a *WSP      ; "enforce",
                        "mx":
                  %x5B                               ; [
                  domain-match                       ; comma-separated list
                  [WSP %x2c domain-match WSP]        ; of domain-matches
                  %x5B                               ; ]

sts-max_age     = %x22 "max_age" %x22 *WSP $x3a *WSP ; ["*.mail.example.com"],
                        "max_age":
                  1*10DIGIT                          ; some digits

domain-match    = %x22 1*(dtext / "*") *("."         ; wildcard or label
                  1*dtext) %x22                      ; with 0+ more labels

dtext           = ALPHA / DIGIT / %2D                ; A-Z, a-z, 0-9, "-" 123456
                      }

   A size limitation in a sts-uri, if provided, is interpreted as a
   count of units followed by an OPTIONAL unit size ("k" for kilobytes,
   "m" for megabytes, "g" for gigabytes, "t" for terabytes).  Without a
   unit, the number is presumed to be a basic byte count.  Note that the
   units are considered to be powers of two; a kilobyte is 2^10, a
   megabyte is 2^20, etc.

3.2.  Policy Expirations

   In order to resist attackers inserting a fraudulent policy, SMTP MTA-
   STS policies are designed to be long-lived, with an expiry typically
   greater than two weeks.  Policy validity is controlled by two
   separate expiration times: the lifetime indicated in the policy
   ("max_age=") and the TTL on the DNS record itself.  The policy
   expiration will ordinarily be longer than that of the DNS TTL, lenient parser SHOULD accept TXT records and
   senders SHOULD cache a policy (and apply it to all mail to the
   recipient domain) until the policy expiration.

   An important consideration files which are
   syntactically valid (i.e. valid key-value pairs separated by semi-
   colons for TXT records and valid JSON for domains publishing a policy is that
   senders will see files) and
   implementing a policy expiration as relative to the fetch superset of this specification, in which case unknown
   fields SHALL be ignored.

3.3.  HTTPS Policy Fetching

   When fetching a new policy cached by their recursive resolver.  Consequently, or updating a sender
   MAY treat policy, the HTTPS endpoint
   MUST present a policy as TLS certificate which is valid for up to {expiration time} + {DNS TTL}.
   Publishers SHOULD thus continue to expect senders to apply old
   policies for up to this duration.

3.2.1.  Policy Updates

   Updating the policy requires that the owner make changes in two
   places: the "_mta_sts" RR record "mta-sts" host
   (as described in [RFC6125]), chain to a root CA that is trusted by
   the Policy Domain's DNS zone sending MTA, and
   at the corresponding HTTPS endpoint.  In the case where the HTTPS
   endpoint has been updated but the TXT record has not been, senders
   will not know there be non-expired.  It is expected that sending
   MTAs use a new policy released set of trusted CAs similar to those in widely deployed Web
   browsers and operating systems.

   HTTP 3xx redirects MUST NOT be followed.

   Senders may thus continue wish to
   use old, previously cached versions.  Recipients should thus expect a
   policy will continue rate-limit the frequency of attempts to be used by senders until both fetch the
   HTTPS and
   TXT endpoints are updated and the TXT record's TTL has passed.

3.3.  Policy Discovery & Authentication

   Senders discover endpoint even if a recipient domain's STS policy, by making an
   attempt to fetch valid TXT records from record for the recipient domain's DNS zone domain
   exists.  In the case that the HTTPS GET fails, we suggest
   implementions may limit further attempts to a period of five minutes
   or longer per version ID, to avoid overwhelming resource-constrained
   recipients with cascading failures.

   Senders MAY impose a timeout on the name "_mta_sts".  A valid TXT record presence in
   "_mta_sts.example.com" indicates that the recipent domain supports
   STS.  To allow recipient domains HTTPS GET to safely serve new policies, it avoid long delays
   imposed by attempted policy updates.  A suggested timeout is
   important that senders are able one
   minute; policy hosts SHOULD respond to authenticate requests with a new complete
   policy
   retrieved body within that timeout.

3.4.  Policy Selection for Smart Hosts

   When sending mail via a recipient domain.

   Web PKI is "smart host"--an intermediate SMTP relay
   rather than the mechanism used for policy authentication.  In this
   mechanism, message recipient's server--compliant senders MUST
   treat the sender fetches a HTTPS resource (policy) from a smart host
   at "policy.mta-sts" in domain as the Policy Domain.  The policy is served from
   a "well known" URI: "https://policy.mta-sts.example.com/.well-known/
   mta-sts/current".  To consider domain for the purposes of
   policy as valid, the "policy_id"
   field in discovery and application.

4.  Policy Validation

   When sending to an MX at a domain for which the policy sender has a valid
   and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS
   MUST match validate:

   1.  That the "id" field in recipient MX matches the DNS TXT record
   under "_mta_sts".

   When fetching a new policy or updating "mx" pattern from the recipient
       domain's policy.

   2.  That the recipient MX supports STARTTLS and offers a policy, valid PKIX
       based TLS certificate.

   This section does not dictate the new policy MUST
   be fully authenticated (HTTPS certificate behavior of sending MTAs when
   policies fail to validate; in particular, validation + peer
   verification) before use.  A policy failures of
   policies which has not ever been
   successfully authenticated specify "report" mode MUST NOT be used to reject mail.

3.4.  Policy Validation interpreted as
   delivery failures, as described in the section _Policy_
   _Application_.

4.1.  MX Matching

   When sending delivering mail for the Policy Domain to an MX at a domain recipient MX host,
   the sender validates the MX match against the "mx" pattern from the
   applied policy.  The semantics for these patterns are those found in
   section 6.4 of [RFC6125].

   Patterns may contain a wildcard character "*" which matches any
   single domain name component or component fragment, though only as
   the sender has leftmost component in a valid
   and non-expired SMTP MTA-STS policy, pattern.  For example, "*.example.com" is
   a sending MTA honoring SMTP MTA-
   STS MUST validate that valid pattern, but "foo.*.example.com" is not.  Given the recipient MX supports STARTTLS, and offers pattern
   "*.example.com", "mx1.example.com" is a valid PKIX based TLS certificate. MX host, but
   "1234.dhcp.example.com" is not.

4.2.  MX Certificate Validation

   The certificate presented by the receiving MX MUST be valid for the
   MX name hostname and chain to a root CA that is trusted by the sending
   MTA.  The certificate MUST have a CN or SAN matching the MX hostname
   (as described in [RFC6125]) and be non-expired.

3.5.

   In the case of an "implicit" MX record (as specified in [RFC2821])
   where no MX RR exists for the recipient domain but there is an A RR,
   the MX hostname is assumed to be that of the A RR and should be
   validated as such.

5.  Policy Application

   When sending to an MX at a domain for which the sender has a valid valid,
   non-expired SMTP MTA-STS STS policy, a sending MTA honoring SMTP MTA-STS
   MAY apply STS applies the
   result of a policy validation one of two ways:

   o ways, depending on the value
   of the policy "mode" field:

   1.  "report": In this mode, sending MTAs merely send a report to (as
       described in the
      designated report address TLSRPT specification (TODO: add ref)) indicating
       policy application failures.
      This can be done "offline", i.e. based on the MTA logs, and is
      thus a suitable low-risk option for MTAs who wish to enhance
      transparency of TLS tampering without making complicated changes
      to production mail-handling infrastructure.

   o

   2.  "enforce": In this mode, sending MTAs SHOULD treat STS policy
      failures, in which the policy action is "reject", failures
       as a mail delivery error, and SHOULD terminate MUST NOT deliver the SMTP connection, not
      delivering any more mail message to the recipient MTA.

   In
       this host.

   When a message fails to deliver due to an "enforce" mode, however, sending MTAs policy, a
   compliant MTA MUST first check for a new
   authenticated the presence of an updated policy at the
   Policy Domain before actually treating a message permanently failing to deliver the message.

   This allows implementing domains to update long-lived policies on the
   fly.

   Finally, in both "enforce" and "report" modes, failures to deliver in
   compliance with the applied policy result in failure reports to the
   policy domain, as described in the TLSRPT specification (TODO: add
   ref).

5.1.  MX Preference

   When applying a policy, sending MTAs SHOULD select recipient MXs by
   first eliminating any MXs at lower priority than the current host (if
   in the MX candidate set), then eliminating any non-matching (as
   specified by the STS Policy) MX hosts from the candidate MX set, and
   then attempting delivery to matching hosts as
   fatal.

   Thus indicated by their MX
   priority, until delivery succeeds or the MX candidate set is empty.

5.2.  Policy Application Control Flow

   An example control flow for a sending MTA that does online policy
   application compliant sender consists of the
   following steps:

   1.  Check for a cached non-expired policy. policy whose time-since-fetch has not exceeded
       its "max_age".  If none exists, attempt to fetch the
       latest, authenticate and cache it. a new policy.
       (Optionally, sending MTAs may unconditionally check for a new
       policy at this step.)

   2.  Validate recipient MTA  Filter candidate MXs against the current policy.  If valid, deliver mail.

   3.  If not no candidate MXs are valid and the policy specifies reporting, mode is "enforce",
       temporarily fail the message.  (Otherwise, generate report.

   4.  If a failure
       report but deliver as though MTA STS were not valid implemented.)

   4.  For each candidate MX, in order of MX priority, attempt to
       deliver the message, enforcing STARTTLS and policy specifies rejection, perform the MX host's PKIX
       certificate validation.

   5.  Upon message retries, a message MAY be permanently failed
       following steps:

       *  Check first checking for a new (non-cached) authenticated policy.

       *  If one exists and the presence of a new policy is different, update (as
       indicated by the
          current policy and go to step 2.

       *  If one exists and "id" field in the "_mta-sts" TXT record).

6.  Operational Considerations

6.1.  Policy Updates

   Updating the new policy is same as requires that the cached policy,
          treat owner make changes in two
   places: the delivery as a failure.

       *  If none exists and cached policy is not expired, treat "_mta-sts" TXT record in the
          delivery as a failure.

   Understanding Policy Domain's DNS zone and
   at the details of step 4 is critical to understanding corresponding HTTPS endpoint.  In the
   behavior of case where the system as a whole.

   Remember that each policy HTTPS
   endpoint has an expiration time (which SHOULD be
   long, on the order of days or months) and a validation method.  With
   these two mechanisms and been updated but the procedure specified in step 4,
   recipients who publish TXT record has not yet been,
   senders will not know there is a new policy have, in effect, a means of updating released and may thus
   continue to use old, previously cached versions.  Recipients should
   thus expect a cached policy at arbitrary intervals, without the risks (of a man-
   in-the-middle attack) they would incur if they were will continue to shorten the
   policy expiration time.

4.  Failure Reporting

   Aggregate statistics on policy failures MAY be reported using used by senders until both
   the
   "TLSRPT" reporting specification (TODO: Add Ref).

5.  IANA Considerations

   There HTTPS and TXT endpoints are no updated and the TXT record's TTL has
   passed.

7.  IANA considerations at this time.

6. Considerations

   A new .well-known URI will be registered in the Well-Known URIs
   registry as described below:

   URI Suffix: mta-sts.json Change Controller: IETF

8.  Security Considerations

   SMTP Strict Transport Security protects attempts to protect against an active
   attacker who wishes to intercept or tamper with mail between hosts
   who support STARTTLS.  There are two classes of attacks considered:

   o

   1.  Foiling TLS negotiation, for example by deleting the "250
       STARTTLS" response from a server or altering TLS session
       negotiation.  This would result in the SMTP session occurring
       over plaintext, despite both parties supporting TLS.

   o

   2.  Impersonating the destination mail server, whereby the sender
       might deliver the message to an impostor, who could then monitor
       and/or modify messages despite opportunistic TLS.  This
       impersonation could be accomplished by spoofing the DNS MX record
       for the recipient domain, or by redirecting client connections
       intended for the legitimate recipient server (for example, by
      altering BGP routing tables).

   SMTP Strict Transport Security relies on certificate validation via
   PKIX based TLS identity checking [RFC6125].  Attackers who are able legitimate recipient server (for example, by
       altering BGP routing tables).

   SMTP Strict Transport Security relies on certificate validation via
   PKIX based TLS identity checking [RFC6125].  Attackers who are able
   to obtain a valid certificate for the targeted recipient mail service
   (e.g. by compromising a certificate authority) are thus able to
   circumvent STS authentication.

   Since we use DNS TXT records for policy discovery, an attacker who is
   able to block DNS responses can suppress the discovery of an STS
   Policy, making the Policy Domain appear not to have an STS Policy.
   The sender policy cache is designed to resist this attack.

   We additionally consider the Denial of Service risk posed by an
   attacker who can modify the DNS records for a victim domain.  Absent
   SMTP STS, such an attacker can cause a sending MTA to cache invalid
   MX records for a long TTL.  With SMTP STS, the attacker can
   additionally advertise a new, long-"max_age" SMTP STS policy with
   "mx" constraints that validate the malicious MX record, causing
   senders to cache the policy and refuse to deliver messages once the
   victim has resecured the MX records.

   This attack is mitigated in part by the ability of a victim domain to
   (at any time) publish a new policy updating the cached, malicious
   policy, though this does require the victim domain to both obtain a
   valid CA-signed certificate for and to understand and properly configure
   SMTP STS.

   Similarly, we consider the targeted recipient mail service possibilty of domains that deliberately
   allow untrusted users to serve untrusted content on user-specified
   subdomains.  In some cases (e.g. by compromising a certificate authority) are thus out the service Tumblr.com) this takes
   the form of scope providing HTTPS hosting of user-registered subdomains; in
   other cases (e.g. dynamic DNS providers) this threat model.

   Since we use takes the form of
   allowing untrusted users to register custom DNS TXT record for policy discovery, an attacker who records at the
   provider's domain.

   In these cases, there is a risk that untrusted users would be able to block DNS responses can suppress the discovery of an STS
   Policy, making
   serve custom content at the Policy Domain appear not to have "mta-sts" host, including serving an
   illegitimate SMTP STS Policy.
   The caching model described in _Policy_ _Expirations_ is designed to
   resist policy.  We believe this attack, and there attack is discussion in rendered
   more difficult by the _Future_ _Work_
   section around future distribution mechanisms that are robust against
   this attack.

7.  Future Work

   The authors would like to suggest multiple considerations need for future
   discussion.

   o  Certificate pinning: One potential improvement in the robustness
      of attacker to both inject malicious
   (but temporarily working) MX records and also serve the certificate validation methods discussed would be "_mta-sts"
   TXT record on the
      deployment of public-key pinning as defined for HTTP in [RFC7469].
      A policy extension supporting these semantics would enable Policy
      Domains same domain--something not, to specify certificates that MUST appear in the MX
      certificate chain, thus providing resistence against compromised
      CA or DNSSEC zone keys.

   o  Policy distribution: As with Certificate Transparency ([RFC6962]),
      it may be possible our knowledge,
   widely provided to provide a verifiable log of policy
      _observations_ (meaning which policies have been observed untrusted users.  This attack is additionally
   mitigated by the aforementioned ability for a
      given Policy Domain).  This would provide insight into policy
      spoofing or faked victim domain to update
   an invalid policy non-existence.  This may be particularly
      useful for Policy Domains not using DNSSEC, since it would provide
      sending MTAs at any future date.

   Even if an authoritative source for whether attacker cannot modify a policy is
      expected served policy, the potential
   exists for a given domain.

   o  Receive-from restrictions: Policy publishers may wish to also
      indicate configurations that allow attackers on the same domain to domains _receiving_
   receive mail from the Policy Domain for that
      all such mail domain.  For example, an easy configuration
   option when authoring an STS Policy for "example.com" is expected to be sent via TLS.  This may allow
      policy publishers to receive reports indicating sending MTA
      misconfigurations.  However, the security properties of a
      "receiver-enforced" system differ from those of set the current
      design; in particular, an active man-in-the-middle attacker may be
      able
   "mx" equal to exploit misconfigured sending MTAs "*.example.com"; recipient domains must consider in a way
   this case the risk that would not
      be possible today with any user possessing a sender-enforced model.

   o  Cipher valid hostname and TLS version restrictions: CA-
   signed certificate (for example, "dhcp-123.example.com") will, from
   the perspective of STS Policy publishers may also
      wish to restrict TLS negotiation to specific ciphers or TLS
      versions.

8.  Appendix 1: Validation Pseudocode

policy = policy_from_cache()
if not policy or is_expired(policy):
  policy = policy_from_https_endpoint()  // fetch and authenticate!
  update_cache = true
if policy:
  if invalid_mx_or_tls(policy):  // check validation, be a valid MX and TLS cert
    if rua:
      generate_report()
    if p_reject():
      policy = policy_from_https_endpoint()  // fetch and authenticate #2!
      update_cache = true
      if invalid_mx_or_tls(policy):
        reject_message()
        update_cache = false
  if update_cache:
    cache(policy) host for that
   domain.

9.  Contributors

   Nicolas Lidzborski Google, Inc nlidz (at) google (dot com)

   Wei Chuang Google, Inc weihaw (at) google (dot com)

   Brandon Long Google, Inc blong (at) google (dot com)

   Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com)
   Klaus Umbach 1&1 Mail & Media Development & Technology GmbH
   klaus.umbach (at) 1und1 (dot de)

   Markus Laber 1&1 Mail & Media Development & Technology GmbH
   markus.laber (at) 1und1 (dot de)

10.  Appendix 2: 1: Domain Owner STS example record

9.1.

10.1.  Example 1

   The owner of example.com "example.com" wishes to begin using STS with a policy
   that will solicit aggregate feedback reports from receivers without affecting how the
   messages are processed, in order to:

   o  Verify to verify the identity of MXs that
   handle mail for this domain

   o  Confirm "example.com", confirm that its legitimate messages are sent over TLS

   o  Verify the validity of the is correctly used,
   and ensure that certificates

   o  Determine how many messages would be affected by a strict policy

   DNS presented by the recipient MX validate.

   STS policy indicator TXT record:

               _mta_sts RR:

       _mta-sts.example.com.  IN TXT ( "v=STSv1; id=randomstr;" ) id=20160831085700Z;"

   STS policy Policy JSON served from HTTPS endpoint of as the policy (recipient)
   domain, and is authenticated using Web PKI mechanism.  The policy is
   fetched using HTTP GET method. response body at [1]

              {
                "version": "STSv1",
                "mode": "report",
                        "policy_id": "randomstr",
                "mx": ["*.mail.example.com"], ["mx1.example.com", "mx2.example.com"],
                "max_age": 123456
              }

   The policy is authenticated using Web PKI mechanism.

10.

11.  Appendix 3: DEEP Registration Elements

Name: mx-mismatch
Description: This indicates that the MX resolved for the recipient domain
             did not match the MX constraint specified in 2: Message delivery pseudocode

   Below is pseudocode demonstrating the policy.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors logic of this document
Change Controller:  IESG

Name: certificate-name-mismatch
Description: a complaint sending
   MTA.  This indicates that implements the subject CNAME/SAN in "two-pass" approach, first attempting
   delivery with a newly fetched policy (if present) before falling back
   to a cached policy (if present).

func isEnforce(policy) {
  // Return true if the certificate
             presented by policy mode is "enforce".
}

func isNonExpired(policy) {
  // Return true if the receiving MX did policy is not match expired.
}

func tryStartTls(mx) {
  // Attempt to open an SMTP connection with STARTTLS with the MX hostname
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: invalid-certificate
Description: This indicates that MX.

}

func certMatches(connection, mx) {
  // Return if the server certificate presented by from "connection" matches the receiving MX
             did not validate "mx" host.
}

func tryDeliverMail(connection, message) {
  // Attempt to deliver "message" via "connection".
}

func getMxsForPolicy(domain, policy) {
  // Sort the MXs by priority, filtering out those which are invalid according
  // to "policy".
}

func tryGetNewPolicy(domain) {
  // Check for an MTA STS TXT record for "domain" in DNS, and return the
  // indicated policy validation constraint.
             (Either it was not signed by (or a trusted CA or did not match local cache of the
             DANE TLSA record unvalidated policy).
}

func cachePolicy(domain, policy) {
  // Store "policy" as the cached policy for "domain".
}

func tryGetCachedPolicy(domain, policy) {
  // Return a cached policy for "domain".
}

func reportError(error) {
  // Report an error via TLSRPT.
}

func tryMxAccordingTo(message, mx, policy) {
  connection := connect(mx)
  if !connection {
    return false  // Can't connect to the MX so it's not an STS error.
  }
  status := !(tryStartTls(mx, &connection) && certMatches(connection, mx))
  status = true
  if !tryStartTls(mx, &connection) {
    status = false
    reportError(E_NO_VALID_TLS)
  } else if certMatches(connection, mx) {
    status = false
    reportError(E_CERT_MISMATCH)
  }
  if status || !isEnforce(policy) {
    return tryDeliverMail(connection, message)

  }
  return false
}

func tryWithPolicy(message, domain, policy) {
  mxes := getMxesForPolicy(domain, policy)
  if mxs is empty {
    reportError(E_NO_VALID_MXES)
  }
  for mx in mxes {
    if tryMxAccordingTo(message, mx, policy) {
      return true
    }
  }
  return false
}

func handleMessage(message) {
  domain := ... // domain part after '@' from recipient MX.)
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: certificate-name-constraints-not-permitted
Description: The certificate request contains a name that
  oldPolicy := tryGetCachedPolicy(domain)
  newPolicy := tryGetNewPolicy(domain)
  if newPolicy {
    cachePolicy(domain, newPolicy)
    oldPolicy = newPolicy
  }
  if oldPolicy {
    return tryWithPolicy(message, oldPolicy)
  }
  // There is not listed as
             permitted in the name constraints extension of the cert issuer.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: certificate-name-constraints-excluded
Description: The certificate request contains no policy or there's a name that is listed as
             excluded in the name constraints extension of the issuer.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: expired-certificate
Description: This indicates that the certificate has expired.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: starttls-not-supported
Description: This indicates new policy that the recipient MX did not support STARTTLS.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: tlsa-invalid
Description: This indicates a validation error for Policy Domain specifying
             "tlsa" validation.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: dnssec-invalid
Description: This indicates a failure work.
  // Try to validate DNS records for a Policy
             Domain specifying "tlsa" validation or "dnssec" authentication.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: sender-does-not-support-validation-method
Description: This indicates the sending system can never validate using deliver the
             requested validation mechanism.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG
11. message normally (i.e. without STS).
}

12.  References

12.1.  Normative References

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

   [RFC2821]  Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
              2821, DOI 10.17487/RFC2821, April 2001,
              <http://www.rfc-editor.org/info/rfc2821>.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <http://www.rfc-editor.org/info/rfc3207>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, 10
              .17487/RFC4627, July 2006,
              <http://www.rfc-editor.org/info/rfc4627>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, 10.17487/
              RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10
              .17487/RFC5785, April 2010,
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <http://www.rfc-editor.org/info/rfc6125>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <http://www.rfc-editor.org/info/rfc7469>.

   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
              Opportunistic DNS-Based Authentication of Named Entities
              (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, 10
              .17487/RFC7672, October 2015,
              <http://www.rfc-editor.org/info/rfc7672>.

12.2.  URIs

   [1] https://mta-sts.example.com/.well-known/mta-sts.json:

Authors' Addresses

   Daniel Margolis
   Google, Inc

   Email: dmargolis (at) google.com
   Mark Risher
   Google, Inc

   Email: risher (at) google (dot com)

   Nicolas Lidzborski
   Google, Inc

   Email: nlidz (at) google (dot com)

   Wei Chuang
   Google, Inc

   Email: weihaw (at) google (dot com)

   Brandon Long
   Google, Inc

   Email: blong (at) google (dot com)

   Binu Ramakrishnan
   Yahoo!, Inc

   Email: rbinu (at) yahoo-inc (dot com)

   Alexander Brotman
   Comcast, Inc

   Email: alexander_brotman (at) cable.comcast (dot com)

   Janet Jones
   Microsoft, Inc

   Email: janet.jones (at) microsoft (dot com)
   Franck Martin
   LinkedIn

   Email: fmartin (at) linkedin (dot com)

   Klaus Umbach
   1&1 Mail & Media Development & Technology GmbH

   Email: klaus.umbach (at) 1und1 (dot de)

   Markus Laber
   1&1 Mail & Media Development & Technology GmbH

   Email: markus.laber (at) 1und1 (dot de)