Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track N. Lidzborski Expires: September 19, 2016 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 March 18, 2016 SMTP Strict Transport Security draft-margolis-smtp-sts-00 Abstract SMTP 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 sending SMTP servers to report upon and/or refuse to deliver messages that cannot be delivered securely. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 September 19, 2016. Margolis, et al. Expires September 19, 2016 [Page 1]

Internet-Draft SMTP-STS March 2016 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 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2.1. Differences from DANE . . . . . . . . . . . . . . . . . . 4 2.2. Advantages When Used with DANE . . . . . . . . . . . . . 4 2.3. Advantages When Used Without DANE . . . . . . . . . . . . 4 2.4. Disadvantages When Used Without DANE . . . . . . . . . . 5 3. Policy Semantics . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 3.2. Policy Expirations . . . . . . . . . . . . . . . . . . . 8 3.3. Policy Authentication . . . . . . . . . . . . . . . . . . 8 3.4. Policy Validation . . . . . . . . . . . . . . . . . . . . 9 3.5. Policy Application . . . . . . . . . . . . . . . . . . . 9 4. Failure Reporting . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Appendix 1: Validation Pseudocode . . . . . . . . . . . . . . 14 9. Appendix 2: Domain Owner STS example record . . . . . . . . . 14 10. Appendix 3: XML Schema for Failure Reports . . . . . . . . . 14 11. Appendix 4: Example report . . . . . . . . . . . . . . . . . 16 12. Normative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1 . Introduction RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. In its current form, however, it fails to provide (a) message confidentiality -- because opportunistic STARTTLS is subject to downgrade attacks -- and Margolis, et al. Expires September 19, 2016 [Page 2]

Internet-Draft SMTP-STS March 2016 (b) server authenticity -- because the trust relationship from email domain to MTA server identity is not cryptographically validated. While such "opportunistic" encryption protocols provide a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform such a downgrade or interception attack. This document defines a mechanism for recipient domains to publish policies specifying: o whether MTAs sending mail to this domain can expect TLS support o how MTAs can validate the TLS server certificate presented during mail delivery o what an implementing sender should do with messages when TLS cannot be be successfully negotiated The mechanism described is separated into four logical components: 1. policy semantics: whether senders can expect a server for the recipient domain to support TLS encryption and how to validate the TLS certificate presented 2. policy authentication: how to determine the authenticity of a published policy delivered via DNS 3. failure report format: a mechanism for informing recipient domains about aggregate failure statistics 4. failure handling: what sending MTAs should do in the case of policy failures 1.1 . Terminology RFC2119]. We also define the following terms for further use in this document: o STS Policy: A definition of the expected TLS availability and behavior, as well as the desired actions for a given domain when a sending MTA encounters different results. Margolis, et al. Expires September 19, 2016 [Page 3]

Internet-Draft SMTP-STS March 2016 o Policy Domain: The domain against which an STS Policy is defined. 2 . Related Technologies RFC7672] is similar, in that DANE is also designed to upgrade opportunistic encryption into required encryption. DANE requires DNSSEC [RFC4033] for the secure delivery of policies; the mechanism described here presents a variant for systems not yet supporting DNSSEC, and specifies a method for reporting TLS negotiation failures. 2.1 . Differences from DANE RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC. (For a thorough discussion of this trade-off, see the section _Security_ _Considerations_.) In addition, SMTP STS introduces a mechanism for failure reporting and a report-only mode, enabling progressive roll-out and auditing for compliance. 2.2 . Advantages When Used with DANE 2.3 . Advantages When Used Without DANE Margolis, et al. Expires September 19, 2016 [Page 4]

Internet-Draft SMTP-STS March 2016 result, a service provider has no choice but to "flip the switch" and affect the entire mail stream at once. 2.4 . Disadvantages When Used Without DANE 3 . Policy Semantics Margolis, et al. Expires September 19, 2016 [Page 5]

Internet-Draft SMTP-STS March 2016 might be handled by any MX whose hostname is a subdomain of "example.com" or "example.net." o a: The mechanism to use to authenticate this policy itself. See the section _Policy_ _Authentication_ for more details. Possible values are: * webpki:URI, where URI points to an HTTPS resource at the recipient domain that serves the same policy text. * dnssec: Indicating that the policy is expected to be served over DNSSEC. o c: Constraints on the recipient MX's TLS certificate (plain-text, required). See the section _Policy_ _Validation_ for more details. Possible values are: * webpki: Indicating that the TLS certificate presented by the recipient MX will be validated according to the "web PKI" mechanism. * tlsa: Indicating that the TLS certificate presented by the recipient MX will match a (presumed to exist) DANE TLSA record. o e: 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 rua: Address to which aggregate feedback MAY be sent (comma- separated plain-text list of email addresses, optional). For example, "mailto:postmaster@example.com" from [RFC3986]. 3.1 . Formal Definition RFC5234], is as follows: Margolis, et al. Expires September 19, 2016 [Page 6]

Internet-Draft SMTP-STS March 2016 sts-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] ; "URI" is imported from [RFC3986]; commas (ASCII ; 0x2C) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer sts-record = sts-version sts-sep sts-to [sts-sep sts-mx] [sts-sep sts-a] [sts-sep sts-c] [sts-sep sts-e] [sts-sep sts-auri] [sts-sep] ; components other than sts-version and ; sts-to may appear in any order sts-version = "v" *WSP "=" *WSP %x53 %x54 %x53 %x31 sts-sep = *WSP %x3b *WSP sts-to = "to" *WSP "=" *WSP ( "true" / "false" ) sts-mx = "mx" *WSP "=" *WSP sts-domain-list sts-domain-list = (domain-match *("," domain-match)) domain-match = ["*."] 1*dtext *("." 1*dtext) dtext = %d30-39 / ; 0-9 %d41-5A / ; a-z %61-7A / ; A-Z %2D ; "-" sts-a = "a" *WSP "=" *WSP ( URI / "dnssec") sts-c = "c" *WSP "=" *WSP ( "webpki" / "tlsa") sts-e = "e" *WSP "=" *WSP 1*6DIGIT sts-auri = "rua" *WSP "=" *WSP sts-uri *(*WSP "," *WSP sts-uri) 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. Margolis, et al. Expires September 19, 2016 [Page 7]

Internet-Draft SMTP-STS March 2016 3.2 . Policy Expirations 3.3 . Policy Authentication RFC5785]. See _Future_ _Work_ for more information.) o DNSSEC: In this mechanism, indicated by the "dnssec" value of the "a" field, the sender MUST retrieve the policy via a DNSSEC signed response for the _smtp_sts TXT record. When fetching a new policy when one is not already known, or when fetching a policy for a domain with an expired policy, unauthenticated policies MUST be trusted and honored. When fetching Margolis, et al. Expires September 19, 2016 [Page 8]

Internet-Draft SMTP-STS March 2016 a policy and authenticating it, as described in detail in _Policy_ _Application_, policies will be authenticated using the mechanism specified by the existing cached policy. Note, however, as described in detail in _Policy_ _Application_, that new policies MUST NOT be considered as valid if they do not validate on first application. That is, a freshly fetched (and unused) policy that has not successfully been applied MUST be disregarded. 3.4 . Policy Validation RFC6125]) and be non-expired. o DANE TLSA: When the "c" field is set to "tlsa", the receiving MX MUST be covered by a DANE TLSA record for the recipient domain, and the presented certificate MUST be valid according to that record (as described by [RFC7672]). A sending MTA who does not support the validation method required-- for example, an MTA that does not have a DNSSEC-compatible resolver-- MUST behave as though the policy did not validate. As described in the section on _Policy_ _Application_, a policy which has not ever been successfully validated MUST not be used to reject mail. 3.5 . Policy Application Margolis, et al. Expires September 19, 2016 [Page 9]

Internet-Draft SMTP-STS March 2016 o Enforced: In this mode, sending MTAs SHOULD treat STS policy failures, in which the policy action is "reject", as a mail delivery error, and SHOULD terminate the SMTP connection, not delivering any more mail to the recipient MTA. In enforced mode, however, sending MTAs MUST first check for a new _authenticated_ policy before actually treating a message failure as fatal. Thus the control flow for a sending MTA that does online policy application consists of the following steps: 1. Check for cached non-expired policy. If none exists, fetch the latest and cache it. 2. Validate recipient MTA against policy. If valid, deliver mail. 3. If policy invalid and policy specifies reporting, generate report. 4. If policy invalid and policy specifies rejection, perform the following steps: * Check for a new (non-cached) _authenticated_ policy. If one exists, update the current policy and go to step 1. * If none exists or the newly fetched policy also fails, treat the delivery as a failure. Understanding the details of step 4 is critical to understanding the behavior of the system as a whole. Remember that each policy has an expiration time (which SHOULD be long, on the order of days or months) and a validation method. With these two mechanisms and the procedure specified in step 4, recipients who publish a policy have, in effect, a means of updating a cached policy at arbitrary intervals, without the risks (of a man- in-the-middle attack) they would incur if they were to shorten the policy expiration time. 4 . Failure Reporting Margolis, et al. Expires September 19, 2016 [Page 10]

Internet-Draft SMTP-STS March 2016 (There may also be a need for enabling more detailed "forensic" reporting during initial stages of a deployment. To address this, the authors consider the possibility of an optional additional "forensic reporting mode" in which more details--such as certificate chains and MTA banners--may be reported. See the section _Future_ _Work_ for more details.) Aggregate reports contain the following fields: o The SMTP STS policy applied (as a string) o The beginning and end of the reporting period Repeated records contain the following fields: o Failure type: This list will start with the minimal set below, and is expected to grow over time based on real-world experience. The initial set is: * mx-mismatch: This indicates that the MX resolved for the recipient domain did not match the MX constraint specified in the policy. * certificate-mismatch: This indicates that the certificate presented by the receiving MX did not match the MX hostname * invalid-certificate: This indicates that the certificate presented by the receiving MX did not validate according to the policy validation constraint. (Either it was not signed by a trusted CA or did not match the DANE TLSA record for the recipient MX.) * expired-certificate: This indicates that the certificate has expired. * starttls-not-supported: This indicates that the recipient MX did not support STARTTLS. * tlsa-invalid: This indicates a validation error for Policy Domain specifying "tlsa" validation. * dnssec-invalid: This indicates a failure to validate DNS records for a Policy Domain specifying "tlsa" validation or "dnssec" authentication. * sender-does-not-support-validation-method: This indicates the sending system can never validate using the requested validation mechanism. Margolis, et al. Expires September 19, 2016 [Page 11]

Internet-Draft SMTP-STS March 2016 o Count: The number of times the error was encountered. o Hostname: The hostname of the recipient MX. Note that the failure types are non-exclusive; an aggregate report MAY contain overlapping counts of failure types where a single send attempt encountered multiple errors. When sending failure reports, sending MTAs MUST NOT honor SMTP STS or DANE TLSA failures. 5 . IANA Considerations RFC5785] (i.e. sending a request to the "wellknown-uri-review@ietf.org" mailing list for review and comment). The proposed URI-suffix is "smtp-sts". 6 . Security Considerations RFC6125] or DANE TLSA [RFC7672]. Attackers who are able to obtain a valid certificate for the targeted recipient mail service (e.g. by compromising a certificate authority) are thus out of scope of this threat model. In the WebPKI constraint mode, an attacker who is able to block DNS responses can suppress the delivery of an STS Policy, making the Policy Domain appear not to have an STS Policy. The caching model described in _Policy_ _Expirations_ is designed to resist this Margolis, et al. Expires September 19, 2016 [Page 12]

Internet-Draft SMTP-STS March 2016 attack, and there is discussion in the _Future_ _Work_ section around future distribution mechanisms that are robust against this attack. 7 . Future Work RFC7469]. A policy extension supporting these semantics would enable Policy Domains to specify certificates that MUST appear in the MX certificate chain, thus providing resistence against compromised CA or DNSSEC zone keys. o Policy distribution: As with Certificate Transparency ([RFC6962]), it may be possible to provide a verifiable log of policy _observations_ (meaning which policies have been observed for a given Policy Domain). This would provide insight into policy spoofing or faked policy non-existence. This may be particularly useful for Policy Domains not using DNSSEC, since it would provide sending MTAs an authoritative source for whether a policy is expected for a given domain. o Receive-from restrictions: Policy publishers may wish to also indicate to domains _receiving_ mail from the Policy Domain that all such mail is expected to be sent via TLS. This may allow policy publishers to receive reports indicating sending MTA misconfigurations. However, the security properties of a "receiver-enforced" system differ from those of the current design; in particular, an active man-in-the-middle attacker may be able to exploit misconfigured sending MTAs in a way that would not be possible today with a sender-enforced model. o Cipher and TLS version restrictions: Policy publishers may also wish to restrict TLS negotiation to specific ciphers or TLS versions. In addition, the authors leave currently open the following details: o Whether and how more detailed "forensic reporting" should be accomplished, as discussed in the section _Failure_ _Reporting_. o The registration of the .well-known/smtp-sts URI as per [RFC5785]. Margolis, et al. Expires September 19, 2016 [Page 13]

Internet-Draft SMTP-STS March 2016 8 . Appendix 1: Validation Pseudocode 9 . Appendix 2: Domain Owner STS example record 10 . Appendix 3: XML Schema for Failure Reports Margolis, et al. Expires September 19, 2016 [Page 14]

Internet-Draft SMTP-STS March 2016 <xs:element name="end" type="xs:integer"/> </xs:all> </xs:complexType> <!-- Report generator metadata. --> <xs:complexType name="ReportMetadataType"> <xs:sequence> <xs:element name="org_name" type="xs:string"/> <xs:element name="email" type="xs:string"/> <xs:element name="extra_contact_info" type="xs:string" minOccurs="0"/> <xs:element name="report_id" type="xs:string"/> <xs:element name="date_range" type="tns:DateRangeType"/> </xs:sequence> </xs:complexType> <!-- The constraints applied in a policy --> <xs:simpleType name="ConstraintType"> <xs:restriction base="xs:string"> <xs:enumeration value="WebPKI"/> <xs:enumeration value="TLSA"/> </xs:restriction> </xs:simpleType> <!-- The policy that was applied at send time. --> <xs:complexType name="AppliedPolicyType"> <xs:all> <xs:element name="domain" type="xs:string"/> <xs:element name="mx" type="xs:string" minOccurs="1" /> <xs:element name="constraint" type="tns:ConstraintType"/> </xs:all> </xs:complexType> <!-- The possible failure types applied in a policy --> <xs:simpleType name="FailureType"> <xs:restriction base="xs:string"> <xs:enumeration value="MxMismatch"/> <xs:enumeration value="InvalidCertificate"/> <xs:enumeration value="ExpiredCertificate"/> <xs:enumeration value="StarttlsNotSupported"/> <xs:enumeration value="TlsaInvalid"/> <xs:enumeration value="DnssecInvalid"/> <xs:enumeration value="SenderDoesNotSupportValidationMethod"/> </xs:restriction> </xs:simpleType> Margolis, et al. Expires September 19, 2016 [Page 15]

Internet-Draft SMTP-STS March 2016 <!-- The possible enforcement level: whether the reporter also drops messages --> <xs:simpleType name="EnforcementLevelType"> <xs:restriction base="xs:string"> <xs:enumeration value="ReportOnly"/> <xs:enumeration value="Reject"/> </xs:restriction> </xs:simpleType> <!-- Record for individual failure types. --> <xs:complexType name="FailureRecordType"> <xs:all> <xs:element name="failure" type="tns:FailureType"/> <xs:element name="count" type="xs:integer"/> <xs:element name="hostname" type="xs:string"/> <xs:element name="connectedIp" type="xs:string" minOccurs="0"/> <xs:element name="sourceIp" type="xs:string" minOccurs="0"/> </xs:all> </xs:complexType> <!-- Parent --> <xs:element name="feedback"> <xs:complexType> <xs:sequence> <xs:element name="version" type="xs:decimal"/> <xs:element name="report_metadata" type="tns:ReportMetadataType"/> <xs:element name="applied_policy" type="tns:AppliedPolicyType"/> <xs:element name="enforcement_level" type="tns:EnforcementLevelType"/> <xs:element name="record" type="tns:FailureRecordType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 11 . Appendix 4: Example report Margolis, et al. Expires September 19, 2016 [Page 16]

Internet-Draft SMTP-STS March 2016 Nicolas Lidzborski Google, Inc Email: nlidz (at) google (dot com) Wei Chuang Google, Inc Email: weihaw (at) google (dot com) Brandon Long Google, Inc Email: blong (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) Janet Jones Microsoft, Inc Email: janet.jones (at) microsoft (dot com) Franck Martin LinkedIn Email: fmartin (at) linkedin (dot com) Klaus Umbach 1&1 Mail & Media Development & Technology GmbH Email: klaus.umbach (at) 1und1 (dot de) Margolis, et al. Expires September 19, 2016 [Page 19]

Internet-Draft SMTP-STS March 2016 Markus Laber 1&1 Mail & Media Development & Technology GmbH Email: markus.laber (at) 1und1 (dot de) Margolis, et al. Expires September 19, 2016 [Page 20]