draft-ietf-uta-mta-sts-02.txt   draft-ietf-uta-mta-sts-03.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: June 18, 2017 B. Ramakrishnan Expires: August 19, 2017 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
December 15, 2016 February 15, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-02 draft-ietf-uta-mta-sts-03
Abstract Abstract
SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a
mechanism enabling mail service providers to declare their ability to mechanism enabling mail service providers to declare their ability to
receive TLS-secured connections and an expected validity of receive TLS-secured connections and an expected validity of
certificates presented by their MX hosts, and to specify whether certificates presented by their MX hosts, and to specify whether
sending SMTP servers should refuse to deliver to MX hosts that do not sending SMTP servers should refuse to deliver to MX hosts that do not
offer TLS with a trusted server certificate. offer TLS with a trusted server certificate.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 18, 2017. This Internet-Draft will expire on August 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 22 skipping to change at page 4, line 22
without performing an HTTPS request. without performing an HTTPS request.
To discover if a recipient domain implements MTA-STS, a sender need To discover if a recipient domain implements MTA-STS, a sender need
only resolve a single TXT record. To see if an updated policy is only resolve a single TXT record. To see if an updated policy is
available for a domain for which the sender has a previously cached available for a domain for which the sender has a previously cached
policy, the sender need only check the TXT record's version "id" policy, the sender need only check the TXT record's version "id"
against the cached value. against the cached value.
3.1. MTA-STS TXT Records 3.1. MTA-STS TXT Records
The MTA-STS TXT record is a TXT record with the name "_mta-sts" at The MTA-STS TXT record is a TXT record with the name "mta-sts" at the
the Policy Domain. For the domain "example.com", this record would Policy Domain. For the domain "example.com", this record would be
be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, "mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII,
semicolon-separated key/value pairs containing the following fields: semicolon-separated key/value pairs containing the following fields:
o "v": (plain-text, required). Currently only "STSv1" is supported. o "v": (plain-text, required). Currently only "STSv1" is supported.
o "id": (plain-text, required). A short string used to track policy o "id": (plain-text, required). A short string used to track policy
updates. This string MUST uniquely identify a given instance of a updates. This string MUST uniquely identify a given instance of a
policy, such that senders can determine when the policy has been policy, such that senders can determine when the policy has been
updated by comparing to the "id" of a previously seen policy. updated by comparing to the "id" of a previously seen policy.
There is no implied ordering of "id" fields between revisions. There is no implied ordering of "id" fields between revisions.
An example TXT record is as below: An example TXT record is as below:
"_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"" "mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;""
The formal definition of the "_mta-sts" TXT record, defined using The formal definition of the "mta-sts" TXT record, defined using
[RFC5234], is as follows: [RFC5234], is as follows:
sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B] sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B]
sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
%x53 %x76 %x31 %x53 %x76 %x31
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
If multiple TXT records for "_mta-sts" are returned by the resolver, If multiple TXT records for "mta-sts" are returned by the resolver,
records which do not begin with "v=STSv1;" are discarded. If the records which do not begin with "v=STSv1;" are discarded. If the
number of resulting records is not one, senders MUST assume the number of resulting records is not one, senders MUST assume the
recipient domain does not implement MTA STS and skip the remaining recipient domain does not implement MTA STS and skip the remaining
steps of policy discovery. steps of policy discovery.
3.2. MTA-STS Policies 3.2. MTA-STS Policies
The policy itself is a JSON [RFC4627] object served via the HTTPS GET The policy itself is a JSON [RFC4627] object served via the HTTPS GET
method from the fixed [RFC5785] "well-known" path of ".well-known/ method from the fixed [RFC5785] "well-known" path of ".well-known/
mta-sts.json" served by the "mta-sts" host at the Policy Domain. mta-sts.json" served by the "mta-sts" host at the Policy Domain.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
3. If no candidate MXs are valid and the policy mode is "enforce", 3. If no candidate MXs are valid and the policy mode is "enforce",
temporarily fail the message. (Otherwise, generate a failure temporarily fail the message. (Otherwise, generate a failure
report but deliver as though MTA STS were not implemented.) report but deliver as though MTA STS were not implemented.)
4. For each candidate MX, in order of MX priority, attempt to 4. For each candidate MX, in order of MX priority, attempt to
deliver the message, enforcing STARTTLS and the MX host's PKIX deliver the message, enforcing STARTTLS and the MX host's PKIX
certificate validation. certificate validation.
5. Upon message retries, a message MAY be permanently failed 5. Upon message retries, a message MAY be permanently failed
following first checking for the presence of a new policy (as following first checking for the presence of a new policy (as
indicated by the "id" field in the "_mta-sts" TXT record). indicated by the "id" field in the "mta-sts" TXT record).
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. In the case where the HTTPS at the corresponding HTTPS endpoint. In the case where the HTTPS
endpoint has been updated but the TXT record has not yet been, endpoint has been updated but the TXT record has not yet been,
senders will not know there is a new policy released and may thus senders will not know there is a new policy released and may thus
continue to use old, previously cached versions. Recipients should continue to use old, previously cached versions. Recipients should
thus expect a policy will continue to be used by senders until both 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 the HTTPS and TXT endpoints are updated and the TXT record's TTL has
passed. passed.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 10, line 27 skipping to change at page 10, line 27
subdomains. In some cases (e.g. the service Tumblr.com) this takes subdomains. In some cases (e.g. the service Tumblr.com) this takes
the form of providing HTTPS hosting of user-registered subdomains; in the form of providing HTTPS hosting of user-registered subdomains; in
other cases (e.g. dynamic DNS providers) this takes the form of other cases (e.g. dynamic DNS providers) this takes the form of
allowing untrusted users to register custom DNS records at the allowing untrusted users to register custom DNS records at the
provider's domain. provider's domain.
In these cases, there is a risk that untrusted users would be able to In these cases, there is a risk that untrusted users would be able to
serve custom content at the "mta-sts" host, including serving an serve custom content at the "mta-sts" host, including serving an
illegitimate SMTP STS policy. We believe this attack is rendered illegitimate SMTP STS policy. We believe this attack is rendered
more difficult by the need for the attacker to both inject malicious more difficult by the need for the attacker to both inject malicious
(but temporarily working) MX records and also serve the "_mta-sts" (but temporarily working) MX records and also serve the "mta-sts" TXT
TXT record on the same domain--something not, to our knowledge, record on the same domain--something not, to our knowledge, widely
widely provided to untrusted users. This attack is additionally provided to untrusted users. This attack is additionally mitigated
mitigated by the aforementioned ability for a victim domain to update by the aforementioned ability for a victim domain to update an
an invalid policy at any future date. invalid policy at any future date.
Even if an attacker cannot modify a served policy, the potential Even if an attacker cannot modify a served policy, the potential
exists for configurations that allow attackers on the same domain to exists for configurations that allow attackers on the same domain to
receive mail for that domain. For example, an easy configuration receive mail for that domain. For example, an easy configuration
option when authoring an STS Policy for "example.com" is to set the option when authoring an STS Policy for "example.com" is to set the
"mx" equal to "*.example.com"; recipient domains must consider in "mx" equal to "*.example.com"; recipient domains must consider in
this case the risk that any user possessing a valid hostname and CA- this case the risk that any user possessing a valid hostname and CA-
signed certificate (for example, "dhcp-123.example.com") will, from signed certificate (for example, "dhcp-123.example.com") will, from
the perspective of STS Policy validation, be a valid MX host for that the perspective of STS Policy validation, be a valid MX host for that
domain. domain.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
10.1. Example 1 10.1. Example 1
The owner of "example.com" wishes to begin using STS with a policy The owner of "example.com" wishes to begin using STS with a policy
that will solicit reports from receivers without affecting how the that will solicit reports from receivers without affecting how the
messages are processed, in order to verify the identity of MXs that messages are processed, in order to verify the identity of MXs that
handle mail for "example.com", confirm that TLS is correctly used, handle mail for "example.com", confirm that TLS is correctly used,
and ensure that certificates presented by the recipient MX validate. and ensure that certificates presented by the recipient MX validate.
STS policy indicator TXT RR: STS policy indicator TXT RR:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
STS Policy JSON served as the response body at [1] STS Policy JSON served as the response body at [1]
{ {
"version": "STSv1", "version": "STSv1",
"mode": "report", "mode": "report",
"mx": ["mx1.example.com", "mx2.example.com"], "mx": ["mx1.example.com", "mx2.example.com"],
"max_age": 123456 "max_age": 123456
} }
skipping to change at page 15, line 17 skipping to change at page 15, line 17
Email: risher (at) google (dot com) Email: risher (at) google (dot com)
Binu Ramakrishnan Binu Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
Email: rbinu (at) yahoo-inc (dot com) Email: rbinu (at) yahoo-inc (dot com)
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
Email: alexander_brotman (at) cable.comcast (dot com) Email: alex_brotman (at) comcast.com
Janet Jones Janet Jones
Microsoft, Inc Microsoft, Inc
Email: janet.jones (at) microsoft (dot com) Email: janet.jones (at) microsoft (dot com)
 End of changes. 14 change blocks. 
20 lines changed or deleted 20 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/