--- 1/draft-ietf-uta-mta-sts-02.txt 2017-02-15 07:13:34.173801101 -0800 +++ 2/draft-ietf-uta-mta-sts-03.txt 2017-02-15 07:13:34.201801760 -0800 @@ -1,24 +1,24 @@ Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track Google, Inc -Expires: June 18, 2017 B. Ramakrishnan +Expires: August 19, 2017 B. Ramakrishnan Yahoo!, Inc A. Brotman Comcast, Inc J. Jones Microsoft, Inc - December 15, 2016 + February 15, 2017 SMTP MTA Strict Transport Security (MTA-STS) - draft-ietf-uta-mta-sts-02 + draft-ietf-uta-mta-sts-03 Abstract SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a mechanism enabling mail service providers to declare their ability to receive TLS-secured connections and an expected validity of certificates presented by their MX hosts, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. @@ -30,25 +30,25 @@ 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 June 18, 2017. + This Internet-Draft will expire on August 19, 2017. 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. 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 @@ -148,48 +148,48 @@ without performing an HTTPS request. 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 available for a domain for which the sender has a previously cached policy, the 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 is a TXT record with the name "_mta-sts" at - the Policy Domain. For the domain "example.com", this record would - be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, + The MTA-STS TXT record is a TXT record with the name "mta-sts" at the + Policy Domain. For the domain "example.com", this record would be + "mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, semicolon-separated key/value pairs containing the following 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. 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;"" + "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: 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, + 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 recipient domain does not implement MTA STS and skip the remaining steps of policy discovery. 3.2. MTA-STS Policies The policy itself is a JSON [RFC4627] object served via the HTTPS GET method from the fixed [RFC5785] "well-known" path of ".well-known/ mta-sts.json" served by the "mta-sts" host at the Policy Domain. @@ -362,28 +362,28 @@ 3. If no candidate MXs are valid and the policy mode is "enforce", temporarily fail the message. (Otherwise, generate a failure report but deliver as though MTA STS were not implemented.) 4. For each candidate MX, in order of MX priority, attempt to deliver the message, enforcing STARTTLS and the MX host's PKIX certificate validation. 5. Upon message retries, a message MAY be permanently failed 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.1. Policy Updates 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 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 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. 7. IANA Considerations @@ -442,25 +442,25 @@ subdomains. In some cases (e.g. the service Tumblr.com) this takes the form of providing HTTPS hosting of user-registered subdomains; in other cases (e.g. dynamic DNS providers) this takes the form of allowing untrusted users to register custom DNS records at the provider's domain. 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 illegitimate SMTP STS policy. We believe this attack is rendered more difficult by the need for the attacker to both inject malicious - (but temporarily working) MX records and also serve the "_mta-sts" - TXT record on the same domain--something not, to our knowledge, - widely provided to untrusted users. This attack is additionally - mitigated by the aforementioned ability for a victim domain to update - an invalid policy at any future date. + (but temporarily working) MX records and also serve the "mta-sts" TXT + record on the same domain--something not, to our knowledge, widely + provided to untrusted users. This attack is additionally mitigated + by the aforementioned ability for a victim domain to update an + invalid policy at any future date. Even if an attacker cannot modify a served policy, the potential exists for configurations that allow attackers on the same domain to receive mail for that domain. For example, an easy configuration option when authoring an STS Policy for "example.com" is to set the "mx" equal to "*.example.com"; recipient domains must consider in this case the risk that any user possessing a valid hostname and CA- signed certificate (for example, "dhcp-123.example.com") will, from the perspective of STS Policy validation, be a valid MX host for that domain. @@ -485,21 +485,21 @@ 10.1. Example 1 The owner of "example.com" wishes to begin using STS with a policy that will solicit reports from receivers without affecting how the messages are processed, in order to verify the identity of MXs that handle mail for "example.com", confirm that TLS is correctly used, and ensure that certificates presented by the recipient MX validate. 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] { "version": "STSv1", "mode": "report", "mx": ["mx1.example.com", "mx2.example.com"], "max_age": 123456 } @@ -668,16 +668,16 @@ Email: risher (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) + Email: alex_brotman (at) comcast.com Janet Jones Microsoft, Inc Email: janet.jones (at) microsoft (dot com)