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
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, 2016

SMTP MTA Strict Transport Security
draft-ietf-uta-mta-sts-01

Abstract

SMTP MTA-STS is a mechanism enabling mail service providers to declare their ability to receive TLS-secured connections, to declare particular methods for certificate validation, and to request that sending SMTP servers report upon and/or refuse to deliver messages that cannot be delivered securely.

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, 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

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 the trust relationship from email domain to MTA server identity is not cryptographically validated.

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.

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

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:

2. Related Technologies

The DANE TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade opportunistic encryption into required 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 the mechanism described here and DANE is that DANE requires the use of DNSSEC to authenticate DANE TLSA records, whereas SMTP STS relies on the certificate authority (CA) system to avoid interception. (For a thorough discussion of this trade-off, see the section Security Considerations.)

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

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

SMTP MTA-STS offers the following advantages compared to DANE:

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

3. Policy Semantics

SMTP MTA-STS policies are distributed via a "well known" HTTPS endpoint in the Policy Domain. A corresponding TXT record in the DNS alerts sending MTAs to the presence of a policy file.

(Future implementations may move to alternate methods of policy discovery or distribution. See the section Future Work for more discussion.)

The MTA-STS TXT record MUST specify the following fields:

A lenient parser SHOULD accept a policy file implementing a superset of this specification, in which case unknown values SHALL be ignored.

Policies MUST specify the following fields in JSON [RFC4627] format:

A lenient parser SHOULD accept a policy file which 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], 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], is as follows:

sts-record      = WSP %x7B WSP  ; { 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    ; "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      ; "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 ; "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, "-" 

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, and senders SHOULD cache a policy (and apply it to all mail to the recipient domain) until the policy expiration.

An important consideration for domains publishing a policy is that senders will see a policy expiration as relative to the fetch of a policy cached by their recursive resolver. Consequently, a sender MAY treat a policy as 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 in the Policy Domain's DNS zone 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 is a new policy released and may thus continue to use old, previously cached versions. Recipients should thus expect a policy will continue to be used by senders until both the HTTPS and TXT endpoints are updated and the TXT record's TTL has passed.

3.3. Policy Discovery & Authentication

Senders discover a recipient domain's STS policy, by making an attempt to fetch TXT records from the recipient domain's DNS zone with 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 to safely serve new policies, it is important that senders are able to authenticate a new policy retrieved for a recipient domain.

Web PKI is the mechanism used for policy authentication. In this mechanism, the sender fetches a HTTPS resource (policy) from a host at policy.mta-sts in 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 the policy as valid, the policy_id field in the policy MUST match the id field in the DNS TXT record under _mta_sts.

When fetching a new policy or updating a policy, the new policy MUST be fully authenticated (HTTPS certificate validation + peer verification) before use. A policy which has not ever been successfully authenticated MUST NOT be used to reject mail.

3.4. Policy Validation

When sending to an MX at a domain for which the sender has a valid and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS MUST validate that the recipient MX supports STARTTLS, and offers a valid PKIX based TLS certificate. The certificate presented by the receiving MX MUST be valid for the MX name 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. Policy Application

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

In enforce mode, however, sending MTAs MUST first check for a new authenticated policy before actually treating a message failure as fatal.

Thus the control flow for a sending MTA that does online policy application consists of the following steps:

  1. Check for cached non-expired policy. If none exists, fetch the latest, authenticate and cache it.
  2. Validate recipient MTA against policy. If valid, deliver mail.
  3. If not valid and the policy specifies reporting, generate report.
  4. If not valid and policy specifies rejection, perform the following steps:

Understanding the details of step 4 is critical to understanding the behavior of the system as a whole.

Remember that each policy has an expiration time (which SHOULD be long, on the order of days or months) and a validation method. With these two mechanisms and the procedure specified in step 4, recipients who publish a policy have, in effect, a means of updating a cached policy at arbitrary intervals, without the risks (of a man-in-the-middle attack) they would incur if they were to shorten the policy expiration time.

4. Failure Reporting

Aggregate statistics on policy failures MAY be reported using the TLSRPT reporting specification (TODO: Add Ref).

5. IANA Considerations

There are no IANA considerations at this time.

6. Security Considerations

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

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 out of scope of this threat model.

Since we use DNS TXT record 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 caching model described in Policy Expirations is designed to resist this attack, and there is discussion in 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 for future discussion.

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 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)

9. Appendix 2: Domain Owner STS example record

9.1. Example 1

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

DNS STS policy indicator TXT record:

_mta_sts  IN TXT ( "v=STSv1; id=randomstr;" )

STS policy served from HTTPS endpoint of the policy (recipient) domain, and is authenticated using Web PKI mechanism. The policy is fetched using HTTP GET method.

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

The policy is authenticated using Web PKI mechanism.

10. 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 the policy.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

Name: certificate-name-mismatch
Description: This indicates that the subject CNAME/SAN in the certificate
             presented by the receiving MX did not match 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 the certificate presented by the receiving MX
             did not validate according to the policy validation constraint.
             (Either it was not signed by a trusted CA or did not match the
             DANE TLSA record for the 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 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 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 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 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 the
             requested validation mechanism.
Intended Usage:  COMMON
Reference:  RFC XXXX (this document once published)
Submitter:  Authors of this document
Change Controller:  IESG

11. 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.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002.
[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.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
[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.
[RFC6962] Laurie, B., Langley, A. and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013.
[RFC7469] Evans, C., Palmer, C. and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015.
[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, October 2015.

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)