--- 1/draft-ietf-uta-mta-sts-00.txt 2016-07-08 16:16:21.680103027 -0700 +++ 2/draft-ietf-uta-mta-sts-01.txt 2016-07-08 16:16:21.712103824 -0700 @@ -1,32 +1,32 @@ Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track N. Lidzborski -Expires: November 13, 2016 W. Chuang +Expires: January 9, 2017 W. Chuang B. Long Google, Inc B. Ramakrishnan Yahoo!, Inc A. Brotman Comcast, Inc J. Jones Microsoft, Inc F. Martin LinkedIn K. Umbach M. Laber 1&1 Mail & Media Development & Technology GmbH - May 13, 2016 + July 8, 2016 SMTP MTA Strict Transport Security - draft-ietf-uta-mta-sts-00 + draft-ietf-uta-mta-sts-01 Abstract SMTP MTA-STS is a mechanism enabling mail service providers to declare their ability to receive TLS-secured connections, to declare particular methods for certificate validation, and to request that sending SMTP servers report upon and/or refuse to deliver messages that cannot be delivered securely. Status of This Memo @@ -37,21 +37,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 October 20, 2016. + This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 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 @@ -201,42 +201,57 @@ o Security: DANE offers an advantage against policy-lookup DoS attacks; that is, while a DNSSEC-signed NXDOMAIN response to a DANE lookup authoritatively indicates the lack of a DANE record, such an option to authenticate policy non-existence does not exist when looking up a policy over plain DNS. 3. Policy Semantics SMTP MTA-STS policies are distributed via a "well known" HTTPS - endpoint in the Policy Domain. + endpoint in the Policy Domain. A corresponding TXT record in the DNS + alerts sending MTAs to the presence of a policy file. (Future implementations may move to alternate methods of policy discovery or distribution. See the section _Future_ _Work_ for more discussion.) - Policies MUST specify the following fields in JSON [RFC4627] format: + *The MTA-STS TXT record MUST specify the following fields:* - o "version": (plain-text, required). Currently only "STS1" is + 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, and + must also match the "policy_id" value of the distributed policy. + + A lenient parser SHOULD accept a policy file implementing a superset + of this specification, in which case unknown values SHALL be ignored. + + *Policies MUST specify the following fields in JSON* [RFC4627] + *format:* + + o "version": (plain-text, required). Currently only "STSv1" is supported. o "mode": (plain-text, required). If "enforce", the receiving MTA requests that messages be delivered only if they conform to the STS policy. If "report" the receiving MTA requests that failure reports be delivered, as specified by the "rua" parameter. o "mx": MX patterns (list of plain-text MX match patterns, required). One or more comma-separated patterns matching the expected MX for this domain. For example, "["*.example.com", "*.example.net"]" indicates that mail for this domain might be handled by any MX whose hostname is a subdomain of "example.com" - or "example.net." The semantics for these patterns should be the + or "example.net". The semantics for these patterns should be the ones found in the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125]. o "max_age": Max lifetime of the policy (plain-text integer seconds). Well-behaved clients SHOULD cache a policy for up to this value from last policy fetch time. o "policy_id": 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 @@ -246,63 +261,64 @@ implementing a superset of this specification, in which case unknown values SHALL be ignored. 3.1. Formal Definition 3.1.1. TXT Record The formal definition of the "_mta_sts" TXT record, defined using [RFC5234], is as follows: - sts-version = "v" *WSP "=" *WSP %x53 %x54 %x53 %x31 + sts-text-record = sts-version *WSP %x3B *WSP sts-id - sts-id = "id" *WSP "=" *WSP 1*20VCHAR + sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" + %x53 %x76 %x31 + + sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) 3.1.2. SMTP MTA-STS Policy The formal definition of the SMTP MTA-STS policy, using [RFC5234], is as follows: sts-record = WSP %x7B WSP ; { left curly bracket sts-element ; comma-separated [ ; list WSP %x2c WSP ; of sts-element ; sts-elements ] WSP %x7d WSP ; } right curly bracket - = %x22 "max + sts-element = sts-version / sts-mode / sts-id / sts-mx / sts-max_age sts-version = %x22 "version" %x22 *WSP %x3a *WSP ; "version": - %x22 %x53 %x54 %x53 %x31 ; "STS1" + %x22 %x53 %x54 %x53 %x76 %x31 ; "STSv1" sts-mode = %x22 "mode" %x22 *WSP %x3a *WSP ; "mode": %x22 ("report" / "enforce") %x22 ; "report"/"enforce" sts-id = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id": - %x22 1*20VCHAR %x22 ; some chars + %x22 1*32(ALPHA / DIGIT) %x22 ; some chars sts-mx = %x22 "mx" $x22 *WSP %x3a *WSP ; "mx": %x5B ; [ domain-match ; comma-separated list [WSP %x2c domain-match WSP] ; of domain-matches %x5B ; ] -sts-max_age = %x22 "max_age" %x22 $x3a *WSP ; "max_age": - %x22 1*10DIGIT %x22$ ; some digits +sts-max_age = %x22 "max_age" %x22 *WSP $x3a *WSP ; "max_age": + 1*10DIGIT ; some digits -domain-match = ["*."] 1*dtext *("." 1*dtext) +domain-match = %x22 1*(dtext / "*") *("." ; wildcard or label + 1*dtext) %x22 ; with 0+ more labels -dtext = %d30-39 / ; 0-9 - %d41-5A / ; a-z - %61-7A / ; A-Z - %2D ; "-" +dtext = ALPHA / DIGIT / %2D ; A-Z, a-z, 0-9, "-" A size limitation in a sts-uri, if provided, is interpreted as a count of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the number is presumed to be a basic byte count. Note that the units are considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc. 3.2. Policy Expirations @@ -339,23 +355,24 @@ attempt to fetch TXT records from the recipient domain's DNS zone with the name "_mta_sts". A valid TXT record presence in "_mta_sts.example.com" indicates that the recipent domain supports STS. To allow recipient domains to safely serve new policies, it is important that senders are able to authenticate a new policy retrieved for a recipient domain. Web PKI is the mechanism used for policy authentication. In this mechanism, the sender fetches a HTTPS resource (policy) from a host at "policy.mta-sts" in the Policy Domain. The policy is served from - a "well known" URI: "https://policy.mta-sts.example.com/current". To - consider the policy as valid, the "policy_id" field in the policy - MUST match the "id" field in the DNS TXT record under "_mta_sts". + a "well known" URI: "https://policy.mta-sts.example.com/.well-known/ + mta-sts/current". To consider the policy as valid, the "policy_id" + field in the policy MUST match the "id" field in the DNS TXT record + under "_mta_sts". When fetching a new policy or updating a policy, the new policy MUST be fully authenticated (HTTPS certificate validation + peer verification) before use. A policy which has not ever been successfully authenticated MUST NOT be used to reject mail. 3.4. Policy Validation When sending to an MX at a domain for which the sender has a valid and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA- @@ -534,28 +551,29 @@ o Verify the validity of the certificates o Determine how many messages would be affected by a strict policy DNS STS policy indicator TXT record: _mta_sts IN TXT ( "v=STSv1; id=randomstr;" ) STS policy served from HTTPS endpoint of the policy (recipient) - domain, and is authenticated using Web PKI mechanism. + domain, and is authenticated using Web PKI mechanism. The policy is + fetched using HTTP GET method. { - "version": "STS1", + "version": "STSv1", "mode": "report", "policy_id": "randomstr", "mx": ["*.mail.example.com"], - "max_age": "123456" + "max_age": 123456 } The policy is authenticated using Web PKI mechanism. 10. Appendix 3: DEEP Registration Elements Name: mx-mismatch Description: This indicates that the MX resolved for the recipient domain did not match the MX constraint specified in the policy. Intended Usage: COMMON @@ -630,62 +648,62 @@ Name: sender-does-not-support-validation-method Description: This indicates the sending system can never validate using the requested validation mechanism. Intended Usage: COMMON Reference: RFC XXXX (this document once published) Submitter: Authors of this document Change Controller: IESG 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [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, + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4627] Crockford, D., "The application/json Media Type for - JavaScript Object Notation (JSON)", RFC 4627, DOI 10 - .17487/RFC4627, July 2006, + JavaScript Object Notation (JSON)", RFC 4627, + DOI 10.17487/RFC4627, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ - RFC5234, January 2008, + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, . [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, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [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, + (DANE) Transport Layer Security (TLS)", RFC 7672, + DOI 10.17487/RFC7672, October 2015, . Authors' Addresses Daniel Margolis Google, Inc Email: dmargolis (at) google.com Mark Risher