draft-ietf-uta-mta-sts-09.txt   draft-ietf-uta-mta-sts-10.txt 
Using TLS in Applications D. Margolis Using TLS in Applications D. Margolis
Internet-Draft M. Risher Internet-Draft M. Risher
Intended status: Standards Track Google, Inc Intended status: Standards Track Google, Inc
Expires: March 9, 2018 B. Ramakrishnan Expires: April 1, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
September 5, 2017 September 28, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-09 draft-ietf-uta-mta-sts-10
Abstract Abstract
SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a
mechanism enabling mail service providers to declare their ability to mechanism enabling mail service providers to declare their ability to
receive Transport Layer Security (TLS) secure SMTP connections, and receive Transport Layer Security (TLS) secure SMTP connections, and
to specify whether sending SMTP servers should refuse to deliver to to specify whether sending SMTP servers should refuse to deliver to
MX hosts that do not offer TLS with a trusted server certificate. MX hosts that do not offer TLS with a trusted server certificate.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2018. This Internet-Draft will expire on April 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 8 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 8
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9
3.5. MX Certificate Validation . . . . . . . . . . . . . . . . 9 3.5. MX Certificate Validation . . . . . . . . . . . . . . . . 9
4. Policy Application . . . . . . . . . . . . . . . . . . . . . 10 4. Policy Application . . . . . . . . . . . . . . . . . . . . . 10
4.1. Policy Application Control Flow . . . . . . . . . . . . . 11 4.1. Policy Application Control Flow . . . . . . . . . . . . . 11
5. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 11 5. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 11
6. Operational Considerations . . . . . . . . . . . . . . . . . 12 6. Operational Considerations . . . . . . . . . . . . . . . . . 12
6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 12 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 12
6.2. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 12 6.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 12
6.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 13 7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 13
7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 13 7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 13
7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 13 7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 14 8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 15
8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 14 8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 15
8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 15 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 16
8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 16 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 16
8.5. Compromise of the Web PKI System . . . . . . . . . . . . 16 8.5. Compromise of the Web PKI System . . . . . . . . . . . . 17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 17 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 17
11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 17 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to negotiate the use of a TLS channel for encrypted mail hosts to negotiate the use of a TLS channel for encrypted mail
transmission. transmission.
While this opportunistic encryption protocol by itself provides a While this opportunistic encryption protocol by itself provides a
high barrier against passive man-in-the-middle traffic interception, high barrier against passive man-in-the-middle traffic interception,
skipping to change at page 10, line 50 skipping to change at page 10, line 50
1. "enforce": In this mode, sending MTAs MUST NOT deliver the 1. "enforce": In this mode, sending MTAs MUST NOT deliver the
message to hosts which fail MX matching or certificate message to hosts which fail MX matching or certificate
validation. validation.
2. "report": In this mode, sending MTAs which also implement the 2. "report": In this mode, sending MTAs which also implement the
TLSRPT specification (TODO: add ref) merely send a report TLSRPT specification (TODO: add ref) merely send a report
indicating policy application failures (so long as TLSRPT is also indicating policy application failures (so long as TLSRPT is also
implemented by the recipient domain). implemented by the recipient domain).
3. "none": In this mode, sending MTAs should treat the policy domain 3. "none": In this mode, sending MTAs should treat the policy domain
as though it does not have any active policy; see Section 6.2, as though it does not have any active policy; see Section 6.3,
"Removing MTA-STS", for use of this mode value. "Removing MTA-STS", for use of this mode value.
When a message fails to deliver due to an "enforce" policy, a When a message fails to deliver due to an "enforce" policy, a
compliant MTA MUST NOT permanently fail to deliver messages before compliant MTA MUST NOT permanently fail to deliver messages before
checking for the presence of an updated policy at the Policy Domain. checking for the presence of an updated policy at the Policy Domain.
(In all cases, MTAs SHOULD treat such failures as transient errors (In all cases, MTAs SHOULD treat such failures as transient errors
and retry delivery later.) This allows implementing domains to and retry delivery later.) This allows implementing domains to
update long-lived policies on the fly. update long-lived policies on the fly.
4.1. Policy Application Control Flow 4.1. Policy Application Control Flow
skipping to change at page 12, line 27 skipping to change at page 12, line 27
message while applying a cache of the recipient's now-outdated policy message while applying a cache of the recipient's now-outdated policy
may be unable to discover that a new policy exists until the DNS TTL may be unable to discover that a new policy exists until the DNS TTL
has passed. Recipients should therefore ensure that old policies has passed. Recipients should therefore ensure that old policies
continue to work for message delivery during this period of time, or continue to work for message delivery during this period of time, or
risk message delays. risk message delays.
Recipients should also prefer to update the HTTPS policy body before Recipients should also prefer to update the HTTPS policy body before
updating the TXT record; this ordering avoids the risk that senders, updating the TXT record; this ordering avoids the risk that senders,
seeing a new TXT record, mistakenly cache the old policy from HTTPS. seeing a new TXT record, mistakenly cache the old policy from HTTPS.
6.2. Removing MTA-STS 6.2. Policy Delegation
Domain owners commonly delegate SMTP hosting to a different
organization, such as an ISP or a Web host. In such a case, they may
wish to also delegate the MTA-STS policy to the same organization
which can be accomplished with two changes.
First, the Policy Domain must point the "_mta-sts" record, via CNAME,
to the "_mta-sts" record maintained by the hosting organization.
This allows the hosting organization to control update signaling.
Second, the Policy Domain must point the "well-known" policy location
to the hosting organization. This can be done either by setting the
"mta-sts" record to a host or CNAME specified by the hosting
organization and by giving the hosting organization a TLS certificate
which is valid for that host, or by setting up a "reverse proxy"
(also known as a "gateway") server that serves as the Policy Domain's
policy the policy currently served by the hosting organization.
For example, given a user domain "user.com" hosted by a mail provider
"provider.com", the following configuration would allow policy
delegation:
DNS:
_mta-sts.user.com. IN CNAME _mta-sts.provider.com.
Policy:
> GET /.well-known/mta-sts.txt
> Host: mta-sts.user.com
< HTTP/1.1 200 OK # Response proxies content from https://mta-sts.provider.com
6.3. Removing MTA-STS
In order to facilitate clean opt-out of MTA-STS by implementing In order to facilitate clean opt-out of MTA-STS by implementing
policy domains, and to distinguish clearly between failures which policy domains, and to distinguish clearly between failures which
indicate attacks and those which indicate such opt-outs, MTA-STS indicate attacks and those which indicate such opt-outs, MTA-STS
implements the "none" mode, which allows validated policies to implements the "none" mode, which allows validated policies to
indicate authoritatively that the policy domain wishes to no longer indicate authoritatively that the policy domain wishes to no longer
implement MTA-STS and may, in the future, remove the MTA-STS TXT and implement MTA-STS and may, in the future, remove the MTA-STS TXT and
policy endpoints entirely. policy endpoints entirely.
A suggested workflow to implement such an opt out is as follows: A suggested workflow to implement such an opt out is as follows:
skipping to change at page 15, line 15 skipping to change at page 15, line 51
string against the TXT record on each successful send, or in a string against the TXT record on each successful send, or in a
background task that runs daily or weekly), an attacker would have to background task that runs daily or weekly), an attacker would have to
foil policy discovery consistently over the lifetime of a cached foil policy discovery consistently over the lifetime of a cached
policy to prevent a successful refresh. policy to prevent a successful refresh.
Additionally, MTAs should alert administrators to repeated policy Additionally, MTAs should alert administrators to repeated policy
refresh failures long before cached policies expire (through warning refresh failures long before cached policies expire (through warning
logs or similar applicable mechanisms), allowing administrators to logs or similar applicable mechanisms), allowing administrators to
detect such a persistent attack on policy refresh. (However, they detect such a persistent attack on policy refresh. (However, they
should not implement such alerts if the cached policy has a "none" should not implement such alerts if the cached policy has a "none"
mode, to allow clean MTA-STS removal, as described in Section 6.2.) mode, to allow clean MTA-STS removal, as described in Section 6.3.)
Resistance to downgrade attacks of this nature--due to the ability to Resistance to downgrade attacks of this nature--due to the ability to
authoritatively determine "lack of a record" even for non- authoritatively determine "lack of a record" even for non-
participating recipients--is a feature of DANE, due to its use of participating recipients--is a feature of DANE, due to its use of
DNSSEC for policy discovery. DNSSEC for policy discovery.
8.3. Denial of Service 8.3. Denial of Service
We additionally consider the Denial of Service risk posed by an We additionally consider the Denial of Service risk posed by an
attacker who can modify the DNS records for a victim domain. Absent attacker who can modify the DNS records for a victim domain. Absent
MTA-STS, such an attacker can cause a sending MTA to cache invalid MX MTA-STS, such an attacker can cause a sending MTA to cache invalid MX
 End of changes. 11 change blocks. 
20 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/