draft-ietf-uta-mta-sts-06.txt   draft-ietf-uta-mta-sts-07.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: December 01, 2017 B. Ramakrishnan Expires: January 2, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
May 31, 2017 June 29, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-06 draft-ietf-uta-mta-sts-07
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 November 26, 2017. This Internet-Draft will expire on January 2, 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 28 skipping to change at page 2, line 28
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 7 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 7
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 8 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 8 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 8
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 9 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 9
5.1. Policy Application Control Flow . . . . . . . . . . . . . 9 5.1. Policy Application Control Flow . . . . . . . . . . . . . 9
6. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Operational Considerations . . . . . . . . . . . . . . . . . 10
6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 10 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 10
8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 11 7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 10
8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 11 7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 12
8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 12
8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 12 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 12
8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 12 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 13 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 14
11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 13 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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,
any attacker who can delete parts of the SMTP session (such as the any attacker who can delete parts of the SMTP session (such as the
skipping to change at page 10, line 5 skipping to change at page 10, line 5
policy at this step. policy at this step.
2. For each candidate MX, in order of MX priority, attempt to 2. For each candidate MX, in order of MX priority, attempt to
deliver the message, enforcing STARTTLS and, assuming a policy is deliver the message, enforcing STARTTLS and, assuming a policy is
present, PKIX certificate validation as described in Section 4.1, present, PKIX certificate validation as described in Section 4.1,
"MX Certificate Validation." "MX Certificate Validation."
3. A message delivery MUST NOT be permanently failed until the 3. A message delivery MUST NOT be permanently failed until the
sender has first checked for the presence of a new policy (as sender has first checked for the presence of a new policy (as
indicated by the "id" field in the "_mta-sts" TXT record). If a indicated by the "id" field in the "_mta-sts" TXT record). If a
new policy is not found, senders SHOULD apply existing rules for new policy is not found, existing rules for the case of temporary
the case of temporary message delivery failures (as discussed in message delivery failures apply (as discussed in [RFC5321]
[RFC5321] section 4.5.4.1). section 4.5.4.1).
6. Operational Considerations 6. Operational Considerations
6.1. Policy Updates 6.1. Policy Updates
Updating the policy requires that the owner make changes in two Updating the policy requires that the owner make changes in two
places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
at the corresponding HTTPS endpoint. As a result, recipients should at the corresponding HTTPS endpoint. As a result, recipients should
expect a policy will continue to be used by senders until both the 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 HTTPS and TXT endpoints are updated and the TXT record's TTL has
skipping to change at page 10, line 33 skipping to change at page 10, line 33
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.
7. IANA Considerations 7. IANA Considerations
7.1. Well-Known URIs Registry
A new .well-known URI will be registered in the Well-Known URIs A new .well-known URI will be registered in the Well-Known URIs
registry as described below: registry as described below:
URI Suffix: mta-sts.json Change Controller: IETF URI Suffix: mta-sts.json Change Controller: IETF
7.2. MTA-STS TXT Record Fields
IANA is requested to create a new registry titled "MTA-STS TXT Record
Fields". The initial entries in the registry are:
+------------+--------------------+------------------------+
| Field Name | Description | Reference |
+------------+--------------------+------------------------+
| v | Record version | Section 3.1 of RFC XXX |
| id | Policy instance ID | Section 3.1 of RFC XXX |
+------------+--------------------+------------------------+
New fields are added to this registry using IANA's "Expert Review"
policy.
7.3. MTA-STS Policy Fields
IANA is requested to create a new registry titled "MTA-STS Policy
Fields". The initial entries in the registry are:
+------------+----------------------+------------------------+
| Field Name | Description | Reference |
+------------+----------------------+------------------------+
| version | Policy version | Section 3.2 of RFC XXX |
| mode | Enforcement behavior | Section 3.2 of RFC XXX |
| max_age | Policy lifetime | Section 3.2 of RFC XXX |
| mx | MX identities | Section 3.2 of RFC XXX |
+------------+----------------------+------------------------+
New fields are added to this registry using IANA's "Expert Review"
policy.
8. Security Considerations 8. Security Considerations
SMTP MTA Strict Transport Security attempts to protect against an SMTP MTA Strict Transport Security attempts to protect against an
active attacker who wishes to intercept or tamper with mail between active attacker who wishes to intercept or tamper with mail between
hosts who support STARTTLS. There are two classes of attacks hosts who support STARTTLS. There are two classes of attacks
considered: considered:
o Foiling TLS negotiation, for example by deleting the "250 o Foiling TLS negotiation, for example by deleting the "250
STARTTLS" response from a server or altering TLS session STARTTLS" response from a server or altering TLS session
negotiation. This would result in the SMTP session occurring over negotiation. This would result in the SMTP session occurring over
 End of changes. 10 change blocks. 
17 lines changed or deleted 54 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/