--- 1/draft-ietf-uta-mta-sts-20.txt 2018-06-15 11:13:19.447181171 -0700 +++ 2/draft-ietf-uta-mta-sts-21.txt 2018-06-15 11:13:19.499182419 -0700 @@ -1,24 +1,24 @@ Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track Google, Inc -Expires: December 8, 2018 B. Ramakrishnan +Expires: December 18, 2018 B. Ramakrishnan Yahoo!, Inc A. Brotman Comcast, Inc J. Jones Microsoft, Inc - June 6, 2018 + June 16, 2018 SMTP MTA Strict Transport Security (MTA-STS) - draft-ietf-uta-mta-sts-20 + draft-ietf-uta-mta-sts-21 Abstract SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Status of This Memo @@ -29,21 +29,21 @@ 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 December 8, 2018. + This Internet-Draft will expire on December 18, 2018. Copyright Notice Copyright (c) 2018 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 @@ -65,29 +65,29 @@ 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 10 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10 4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11 4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11 5.1. Policy Application Control Flow . . . . . . . . . . . . . 12 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12 7. Interoperability Considerations . . . . . . . . . . . . . . . 13 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13 - 8. Operational Considerations . . . . . . . . . . . . . . . . . 13 + 8. Operational Considerations . . . . . . . . . . . . . . . . . 14 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 14 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15 - 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 15 + 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16 - 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 16 + 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 22 @@ -195,21 +195,21 @@ 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 ABNF ([RFC7405]), is as follows: sts-text-record = sts-version 1*(sts-field-delim sts-field) [sts-field-delim] sts-field = sts-id / ; Note that sts-id record sts-extension ; is required. @@ -218,34 +218,35 @@ sts-version = %s"v=STSv1" sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... sts-extension = sts-ext-name "=" sts-ext-value ; name=value sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) - ; chars excluding "=", ";", and control chars + ; chars excluding "=", ";", SP, and CTLs The TXT record MUST begin with sts-version field, and the order of other fields is not significant. 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 have an - available MTA-STS policy and skip the remaining steps of policy - discovery. (Note that absence of a usable TXT record is not by - itself sufficient to remove a sender's previously cached policy for - the Policy Domain, as discussed in Section 5.1, "Policy Application - Control Flow".) If the resulting TXT record contains multiple - strings, then the record MUST be treated as if those strings are - concatenated together without adding spaces. + one, or if the resulting record is syntactically invalid, senders + MUST assume the recipient domain does not have an available MTA-STS + policy and skip the remaining steps of policy discovery. (Note that + absence of a usable TXT record is not by itself sufficient to remove + a sender's previously cached policy for the Policy Domain, as + discussed in Section 5.1, "Policy Application Control Flow".) If the + resulting TXT record contains multiple strings, then the record MUST + be treated as if those strings are concatenated together without + adding spaces. 3.2. MTA-STS Policies The policy itself is a set of key/value pairs (similar to [RFC5322] header fields) served via the HTTPS GET method from the fixed [RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by the Policy Host. The Policy Host DNS name is constructed by prepending "mta-sts" to the Policy Domain. Thus for a Policy Domain of "example.com" the full URL is @@ -305,21 +306,21 @@ [RFC7405], is as follows: sts-policy-record = sts-policy-field *WSP *(sts-policy-term sts-policy-field *WSP) [sts-policy-term] sts-policy-field = sts-policy-version / ; required once sts-policy-mode / ; required once sts-policy-max-age / ; required once - 0*(sts-policy-mx *WSP sts-policy-term) / + sts-policy-term / ; required at least once, except when ; mode is "none" sts-policy-extension ; other fields sts-policy-field-delim = ":" *WSP sts-policy-version = sts-policy-version-field sts-policy-field-delim sts-policy-version-value @@ -324,77 +325,77 @@ sts-policy-version-value sts-policy-version-field = %s"version" sts-policy-version-value = %s"STSv1" sts-policy-mode = sts-policy-mode-field sts-policy-field-delim sts-policy-mode-value sts-policy-mode-field = %s"mode" - sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none" + sts-policy-mx = sts-policy-mx-field sts-policy-field-delim sts-policy-mx-value sts-policy-mx-field = %s"mx" -sts-policy-mx-value = ["*."] *(sts-policy-mx-label ".") - sts-policy-mx-toplabel +sts-policy-mx-value = ["."] Domain -sts-policy-mx-label = sts-policy-alphanum | - sts-policy-alphanum *(sts-policy-alphanum | "-") +sts-policy-mx-label = sts-policy-alphanum / + sts-policy-alphanum *(sts-policy-alphanum / "-") sts-policy-alphanum -sts-policy-mx-toplabel = ALPHA | ALPHA *(sts-policy-alphanum | "-") +sts-policy-mx-toplabel = ALPHA / ALPHA *(sts-policy-alphanum / "-") sts-policy-alphanum sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim sts-policy-max-age-value sts-policy-max-age-field = %s"max_age" sts-policy-max-age-value = 1*10(DIGIT) sts-policy-extension = sts-policy-ext-name ; additional sts-policy-field-delim ; extension sts-policy-ext-value ; fields sts-policy-ext-name = (sts-policy-alphanum) *31(sta-policy-alphanum / "_" / "-" / ".") -sts-policy-term = LF / CR / CRLF +sts-policy-term = LF / CRLF sts-policy-ext-value = sts-policy-vchar [*(%x20 / sts-policy-vchar) sts-policy-vchar] ; chars, including UTF-8 [@!RFC3629], ; excluding CTLs and no ; leading/trailing spaces -sts-policy-alphanum = ALPHA | DIGIT +sts-policy-alphanum = ALPHA / DIGIT sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = UTF8-3 = UTF8-4 = +Domain = + Parsers MUST accept TXT records and policy files which are syntactically valid (i.e., valid key/value pairs separated by semi- colons for TXT records), possibly containing additional key/value pairs not specified in this document, in which case unknown fields SHALL be ignored. If any non-repeated field--i.e., all fields excepting "mx"--is duplicated, all entries except for the first SHALL - be ignored. If any field is not specified, the policy SHALL be - treated as invalid. + be ignored. 3.3. HTTPS Policy Fetching Policy bodies are, as described above, retrieved by sending MTAs via HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present a X.509 certificate which is valid for the "mta-sts" DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the sending MTA, and be non- expired. It is expected that sending MTAs use a set of trusted CAs @@ -450,21 +451,23 @@ problems with policy refresh, MTAs SHOULD alert administrators (through the use of logs or similar) when such attempts fail, unless the cached policy mode is "none". 3.4. Policy Selection for Smart Hosts and Subdomains When sending mail via a "smart host"--an administratively configured intermediate SMTP relay, which is different from the message recipient's server as determined from DNS --compliant senders MUST treat the smart host domain as the policy domain for the purposes of - policy discovery and application. + policy discovery and application. This specification does not + provide a means of associating policies with addresses that employ + Address Literals [RFC5321]. When sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone. Thus for mail sent to "user@mail.example.com", the policy can be fetched only from "mail.example.com", not "example.com". 4. Policy Validation When sending to an MX at a domain for which the sender has a valid and non-expired MTA-STS policy, a sending MTA honoring MTA-STS MUST