| 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 | |
| K. Umbach | |
| M. Laber | |
| 1&1 Mail & Media Development & Technology GmbH | |
| March 18, 2016 |
SMTP Strict Transport Security
draft-margolis-smtp-sts-00
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.
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.
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.
The STARTTLS extension to SMTP [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 (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:
The mechanism described is separated into four logical components:
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
We also define the following terms for further use in this document:
The DANE TLSA record [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.
The primary difference between the mechanism described here and DANE is that DANE requires the use of DNSSEC to authenticate DANE TLSA records, whereas SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [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.
SMTP STS can be deployed for a recipient domain that also publishes a DANE TLSA record for SMTP. In these cases, the SMTP STS policy can additionally declare a process for failure reporting.
When deployed without a DANE TLSA record, SMTP STS offers the following advantages compared to DANE:
When deployed alone (i.e. without a DANE record, and using Web PKI for certificate verification), SMTP STS offers the following disadvantages compared to DANE:
SMTP STS policies are distributed at the Policy Domain either through a new resource record, or as TXT records (similar to DMARC policies) under the name "_smtp_sts.” (Current implementations deploy as TXT records.) For example, for the Policy Domain "example.com", the recipient's SMTP STS policy can be retrieved from "_smtp_sts.example.com."
(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:
The formal definition of the SMTP STS format, using [RFC5234], is as follows:
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.
In order to resist attackers inserting a fraudulent policy, SMTP STS policies are designed to be long-lived, with an expiry typically greater than two weeks. Policy validity is controlled by two separate expiration times: the lifetime indicated in the policy ("e=") and the TTL on the DNS record itself. The policy expiration will ordinarily be longer than that of the DNS TTL, and senders SHOULD cache a policy (and apply it to all mail to the recipient domain) until the policy expiration.
An important consideration for domains publishing a policy is that senders will see a policy expiration as relative to the fetch of a policy cached by their recursive resolver. Consequently, a sender MAY treat a policy as valid for up to {expiration time} + {DNS TTL}. Publishers SHOULD thus continue to expect senders to apply old policies for up to this duration.
The security of a domain implementing an SMTP STS policy against an active man-in-the-middle depends primarily upon the long-lived caching of policies. However, to allow recipient domains to safely serve new policies prior to the expiration of a cached policy, and to prevent long-term (either malicious or active) denials of service, it is important that senders are able to validate a new policy retrieved for a recipient domain. There are two supported mechanisms for policy validation:
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 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.
When sending to an MX at a domain for which the sender has a valid and non-expired SMTP STS policy, a sending MTA honoring SMTP STS SHOULD validate that the recipient MX supports STARTTLS and offers a TLS certificate which is valid according to the semantics of the SMTP STS policy. Policies can specify certificate validity in one of two ways by setting the value of the "c" field in the policy description.
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.
When sending to an MX at a domain for which the sender has a valid non-expired SMTP STS policy, a sending MTA honoring SMTP STS MAY apply the result of a policy validation one of two ways:
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:
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.
Aggregate statistics on policy failures MAY be reported to the URI indicated in the "rua" field of the policy. SMTP STS reports contain information about policy failures to allow diagnosis of misconfigurations and malicious activity.
(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:
Repeated records contain the following fields:
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.
The .well-known URI for Policy Domains to host their STS Policies will be registered by following the procedure documented in [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.
SMTP Strict Transport Security protects against an active attacker who wishes to intercept or tamper with mail between hosts who support STARTTLS. There are two classes of attacks considered:
SMTP Strict Transport Security relies on certificate validation via either TLS identity checking [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 attack, and there is discussion in the Future Work section around future distribution mechanisms that are robust against this attack.
The authors would like to suggest multiple considerations for future discussion.
In addition, the authors leave currently open the following details:
policy = policy_from_cache()
if not policy or is_expired(policy):
policy = policy_from_dns() // fetch and authenticate!
update_cache = true
if policy:
if invalid_mx_or_tls(policy): // check MX and TLS cert
if rua:
generate_report()
if p_reject():
policy = policy_from_dns() // fetch and authenticate #2!
update_cache = true
if invalid_mx_or_tls(policy):
reject_message()
update_cache = false
if update_cache:
cache(policy)
The owner wishes to begin using STS
with a policy that will solicit aggregate feedback from receivers
without affecting how the messages are processed, in order to:
* Confirm that its legitimate messages are sent over TLS
* Verify the validity of the certificates
* Verify what cyphers are in use
* Determine how many messages would be affected by a strict policy
_smtp_sts IN TXT ( "v=STS1; to=false; "
"rua=mailto:sts-feedback@example.com " )
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/smtp-sts-xml/0.1"
xmlns:tns="http://www.example.org/smtp-sts-xml/0.1">
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"/>
<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>
<!-- 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>
<feedback xmlns="http://www.example.org/smtp-sts-xml/0.1">
<version>1</version>
<report_metadata>
<org_name>Company XYZ</org_name>
<email>sts-reporting@company.com</email>
<extra_contact_info></extra_contact_info>
<report_id>12345</report_id>
<date_range><begin>1439227624</begin>
<end>1439313998</end></date_range>
</report_metadata>
<applied_policy>
<domain>company.com</domain>
<mx>*.mx.mail.company.com</mx>
<constraint>WebPKI</constraint>
</applied_policy>
<enforcement_level>ReportOnly</enforcement_level>
<record>
<failure>ExpiredCertificate</failure>
<count>13128</count>
<hostname>mta7.am0.yahoodns.net.</hostname>
<connectedIp> 98.136.216.25</connectedIp>
</record>
<record>
<failure>StarttlsNotSupported</failure>
<count>19</count>
<hostname>mta7.am0.yahoodns.net.</hostname>
<connectedIp>98.22.33.99</connectedIp>
</record>
</feedback>