--- 1/draft-ietf-uta-mta-sts-07.txt 2017-08-15 10:13:54.104749135 -0700 +++ 2/draft-ietf-uta-mta-sts-08.txt 2017-08-15 10:13:54.144750090 -0700 @@ -1,24 +1,24 @@ Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track Google, Inc -Expires: January 2, 2018 B. Ramakrishnan +Expires: February 16, 2018 B. Ramakrishnan Yahoo!, Inc A. Brotman Comcast, Inc J. Jones Microsoft, Inc - June 29, 2017 + August 15, 2017 SMTP MTA Strict Transport Security (MTA-STS) - draft-ietf-uta-mta-sts-07 + draft-ietf-uta-mta-sts-08 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 January 2, 2018 . + This Internet-Draft will expire on February 16, 2018. Copyright Notice 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 @@ -54,44 +54,44 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 - 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6 - 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 7 - 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 8 - 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Policy Application Control Flow . . . . . . . . . . . . . 9 - 6. Operational Considerations . . . . . . . . . . . . . . . . . 10 - 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 10 - 7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 10 - 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.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 13 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 14 - 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 14 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 7 + 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9 + 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 9 + 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Policy Application Control Flow . . . . . . . . . . . . . 10 + 6. Operational Considerations . . . . . . . . . . . . . . . . . 11 + 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 11 + 7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 12 + 7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 13 + 8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 13 + 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 + 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 14 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 15 + 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to negotiate the use of a TLS channel for encrypted mail transmission. While this opportunistic encryption protocol by itself provides a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the @@ -178,104 +178,142 @@ 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;"" The formal definition of the "_mta-sts" TXT record, defined using - [RFC5234], is as follows: - -sts-text-record = sts-version *WSP field-delim *WSP sts-id - [field-delim [sts-extensions]] + [RFC7405], is as follows: -field-delim = %x3B ; ";" +sts-text-record = sts-version field-delim sts-id + *(field-delim sts-extension) [field-delim] -sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" - %x53 %x76 %x31 +field-delim = *WSP ";" *WSP -sts-id = %x69 %x64 *WSP "=" - *WSP 1*32(ALPHA / DIGIT) ; "id=" +sts-version = %s"v=STSv1" -sts-extensions = sts-extension *(field-delim sts-extension) - [field-delim] ; extension fields +sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... -sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value +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 ; "=", ";", SP, and ; control chars 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 [RFC7159] 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. - Thus for "example.com" the path is "https://mta-sts.example.com - /.well-known/mta-sts.json". + The policy itself is a set of key/value pairs served via the HTTPS + GET method from the fixed [RFC5785] "well-known" path of ".well- + known/mta-sts.txt" served by the "mta-sts" host at the Policy Domain; + the [RFC2616] "Content-Type" header MUST be "text/plain". Thus for + "example.com" the path is "https://mta-sts.example.com/.well-known/ + mta-sts.txt". - This JSON object contains the following key/value pairs: + This resource contains the following line-separated key/value pairs: o "version": (plain-text, required). Currently only "STSv1" is supported. o "mode": (plain-text, required). Either "enforce" or "report", indicating the expected behavior of a sending MTA in the case of a policy validation failure. o "max_age": Max lifetime of the policy (plain-text non-negative integer seconds, required). Well-behaved clients SHOULD cache a policy for up to this value from last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value typically be in the range of weeks or greater. o "mx": MX identity patterns (list of plain-text strings, required). One or more patterns matching a Common Name ([RFC6125]) or Subject Alternative Name ([RFC5280]) DNS-ID present in the X.509 certificate presented by any MX receiving mail for this domain. - For example, "["mail.example.com", ".example.net"]" indicates that - mail for this domain might be handled by any MX with a certificate - valid for a host at "mail.example.com" or "example.net". Valid - patterns can be either fully specified names ("example.com") or - suffixes (".example.net") matching the right-hand parts of a - server's identity; the latter case are distinguished by a leading - period. In the case of Internationalized Domain Names + For example: "mx: mail.example.com mx: .example.net" indicates + that mail for this domain might be handled by any MX with a + certificate valid for a host at "mail.example.com" or + "example.net". Valid patterns can be either fully specified names + ("example.com") or suffixes (".example.net") matching the right- + hand parts of a server's identity; the latter case are + distinguished by a leading period. If there are more than one MX + specified by the policy, they MUST be on separate lines within the + policy file. In the case of Internationalized Domain Names ([RFC5891]), the MX MUST specify the Punycode-encoded A-label [RFC3492] and not the Unicode-encoded U-label. The full semantics of certificate validation are described in Section 4.1, "MX Certificate Validation." - An example JSON policy is as below: + An example policy is as below: - { - "version": "STSv1", - "mode": "enforce", - "mx": [".mail.example.com"], - "max_age": 123456 - } + version: STSv1 + mode: enforce + mx: mail.example.com + mx: .example.net + mx: backupmx.example.com + max_age: 123456 + + The formal definition of the policy resource, defined using + [RFC7405], is as follows: + + sts-policy-record = sts-policy-version CRLF + sts-policy-mode CRLF + 1*(sts-policy-mx CRLF) + sts-policy-max-age + + field-delim = ":" *WSP + + sts-policy-version = sts-policy-version-field field-delim + sts-policy-version-value + + sts-policy-version-field = %s"version" + + sts-policy-version-value = %s"STSv1" + + sts-policy-mode = sts-policy-mode-field field-delim + sts-policy-mode-value + + sts-policy-mode-field = %s"mode" + + sts-policy-model-value = %s"report" / %s"enforce" + + sts-policy-mx = sts-policy-mx-field field-delim + sts-policy-mx-value + + sts-policy-mx-field = %s"mx" + + sts-policy-mx-value = 1*(ALPHA / DIGIT / "_" / "-" / ".") + + sts-policy-max-age = sts-policy-max-age-field field-delim + sts-policy-max-age-value + + sts-policy-max-age-field = %s"max_age" + + sts-policy-max-age-value = 1*10(DIGIT) 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 and valid JSON for policy files) and - implementing a superset of this specification, in which case unknown - fields SHALL be ignored. + syntactically valid (i.e. valid key/value pairs separated by semi- + colons for TXT records) and implementing a superset of this + specification, in which case unknown fields SHALL be ignored. If any + field other than "mx" is duplicated, the first entry will be honored, + the rest should be ignored. For the "mx" field, all valid entries + will be utilized when enforcing the stated policy. 3.3. HTTPS Policy Fetching When fetching a new policy or updating a policy, the HTTPS endpoint MUST present a X.509 certificate which is valid for the "mta-sts" host (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 similar to those in widely deployed Web browsers and operating systems. @@ -381,23 +419,24 @@ A simple pseudocode implementation of this algorithm is presented in the Appendix. 5. Policy Application When sending to an MX at a domain for which the sender has a valid, non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies the result of a policy validation failure one of two ways, depending on the value of the policy "mode" field: - 1. "report": In this mode, sending MTAs merely send a report (as - described in the TLSRPT specification (TODO: add ref)) indicating - policy application failures. + 1. "report": In this mode, sending MTAs which also implement the + TLSRPT specification (TODO: add ref) merely send a report + indicating policy application failures (so long as TLSRPT is also + implemented by the recipient domain). 2. "enforce": In this mode, sending MTAs MUST NOT deliver the message to hosts which fail MX matching or certificate validation. When a message fails to deliver due to an "enforce" policy, a compliant MTA MUST NOT permanently fail to deliver messages before checking for the presence of an updated policy at the Policy Domain. (In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later.) This allows implementing domains to @@ -453,21 +492,21 @@ updating the TXT record; this ordering avoids the risk that senders, seeing a new TXT record, mistakenly cache the old policy from HTTPS. 7. IANA Considerations 7.1. Well-Known URIs Registry A new .well-known URI will be registered in the Well-Known URIs registry as described below: - URI Suffix: mta-sts.json Change Controller: IETF + URI Suffix: mta-sts.txt 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 | @@ -628,28 +668,28 @@ policy that will solicit reports from senders 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. MTA-STS policy indicator TXT RR: _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" - MTA-STS Policy JSON served as the response body at [1] + MTA-STS Policy file served as the response body at [1] - { - "version": "STSv1", - "mode": "report", - "mx": ["mx1.example.com", "mx2.example.com"], - "max_age": 12345678 - } + version: STSv1 + mode: report + mx: mx1.example.com + mx: mx2.example.com + mx: mx.backup-example.com + max_age: 12345678 11. Appendix 2: Message delivery pseudocode Below is pseudocode demonstrating the logic of a compliant sending MTA. While this pseudocode implementation suggests synchronous policy retrieval in the delivery path, in a working implementation that may be undesirable, and we expect some implementors to instead prefer a background fetch that does not block delivery if no cached policy is @@ -760,39 +805,40 @@ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, DOI 10 .17487/RFC2560, June 1999, . + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ + RFC2616, June 1999, + . + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ - RFC5234, January 2008, - . - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . @@ -806,49 +852,49 @@ RFC5891, August 2010, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . - [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March - 2014, . + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC + 7405, DOI 10.17487/RFC7405, December 2014, + . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10 .17487/RFC7672, October 2015, . 12.2. URIs - [1] https://mta-sts.example.com/.well-known/mta-sts.json: + [1] https://mta-sts.example.com/.well-known/mta-sts.txt: Authors' Addresses Daniel Margolis Google, Inc Email: dmargolis (at) google.com - Mark Risher Google, Inc Email: risher (at) google (dot com) Binu Ramakrishnan Yahoo!, Inc Email: rbinu (at) yahoo-inc (dot com) + Alexander Brotman Comcast, Inc Email: alex_brotman (at) comcast.com Janet Jones Microsoft, Inc Email: janet.jones (at) microsoft (dot com)