idnits 2.17.1 draft-ietf-uta-mta-sts-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 31, 2017) is 2519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 795 -- Looks like a reference, but probably isn't: '0' on line 647 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Using TLS in Applications D. Margolis 3 Internet-Draft M. Risher 4 Intended status: Standards Track Google, Inc 5 Expires: December 01, 2017 B. Ramakrishnan 6 Yahoo!, Inc 7 A. Brotman 8 Comcast, Inc 9 J. Jones 10 Microsoft, Inc 11 May 31, 2017 13 SMTP MTA Strict Transport Security (MTA-STS) 14 draft-ietf-uta-mta-sts-06 16 Abstract 18 SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a 19 mechanism enabling mail service providers to declare their ability to 20 receive Transport Layer Security (TLS) secure SMTP connections, and 21 to specify whether sending SMTP servers should refuse to deliver to 22 MX hosts that do not offer TLS with a trusted server certificate. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 26, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 61 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 63 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 64 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6 65 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 7 66 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 8 68 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Policy Application Control Flow . . . . . . . . . . . . . 9 70 6. Operational Considerations . . . . . . . . . . . . . . . . . 10 71 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 10 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 11 75 8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 11 76 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 12 77 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 12 78 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 13 80 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 13 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 89 hosts to negotiate the use of a TLS channel for encrypted mail 90 transmission. 92 While this opportunistic encryption protocol by itself provides a 93 high barrier against passive man-in-the-middle traffic interception, 94 any attacker who can delete parts of the SMTP session (such as the 95 "250 STARTTLS" response) or who can redirect the entire SMTP session 96 (perhaps by overwriting the resolved MX record of the delivery 97 domain) can perform downgrade or interception attacks. 99 This document defines a mechanism for recipient domains to publish 100 policies specifying: 102 o whether MTAs sending mail to this domain can expect PKIX- 103 authenticated TLS support 105 o what a conforming client should do with messages when TLS cannot 106 be successfully negotiated 108 1.1. Terminology 110 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 111 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 112 document, are to be interpreted as described in [RFC2119]. 114 We also define the following terms for further use in this document: 116 o MTA-STS Policy: A commitment by the Policy Domain to support PKIX 117 authenticated TLS for the specified MX hosts. 119 o Policy Domain: The domain for which an MTA-STS Policy is defined. 120 This is the next-hop domain; when sending mail to 121 "alice@example.com" this would ordinarly be "example.com", but 122 this may be overriden by explicit routing rules (as described in 123 Section 3.4, "Policy Selection for Smart Hosts and Subdomains"). 125 2. Related Technologies 127 The DANE TLSA record [RFC7672] is similar, in that DANE is also 128 designed to upgrade unauthenticated encryption or plaintext 129 transmission into authenticated, downgrade-resistent encrypted 130 tarnsmission. DANE requires DNSSEC [RFC4033] for authentication; the 131 mechanism described here instead relies on certificate authorities 132 (CAs) and does not require DNSSEC, at a cost of risking malicious 133 downgrades. For a thorough discussion of this trade-off, see 134 Section 8, "Security Considerations". 136 In addition, MTA-STS provides an optional report-only mode, enabling 137 soft deployments to detect policy failures; partial deployments can 138 be achieved in DANE by deploying TLSA records only for some of a 139 domain's MXs, but such a mechanism is not possible for the per-domain 140 policies used by MTA-STS. 142 The primary motivation of MTA-STS is to provide a mechanism for 143 domains to upgrade their transport security even when deploying 144 DNSSEC is undesirable or impractical. However, MTA-STS is designed 145 not to interfere with DANE deployments when the two overlap; in 146 particular, senders who implement MTA-STS validation MUST NOT allow a 147 "valid" or "report-only" MTA-STS validation to override a failing 148 DANE validation. 150 3. Policy Discovery 152 MTA-STS policies are distributed via HTTPS from a "well-known" 153 [RFC5785] path served within the Policy Domain, and their presence 154 and current version are indicated by a TXT record at the Policy 155 Domain. These TXT records additionally contain a policy "id" field, 156 allowing sending MTAs to check the currency of a cached policy 157 without performing an HTTPS request. 159 To discover if a recipient domain implements MTA-STS, a sender need 160 only resolve a single TXT record. To see if an updated policy is 161 available for a domain for which the sender has a previously cached 162 policy, the sender need only check the TXT record's version "id" 163 against the cached value. 165 3.1. MTA-STS TXT Records 167 The MTA-STS TXT record is a TXT record with the name "_mta-sts" at 168 the Policy Domain. For the domain "example.com", this record would 169 be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, 170 semicolon-separated key/value pairs containing the following fields: 172 o "v": (plain-text, required). Currently only "STSv1" is supported. 174 o "id": (plain-text, required). A short string used to track policy 175 updates. This string MUST uniquely identify a given instance of a 176 policy, such that senders can determine when the policy has been 177 updated by comparing to the "id" of a previously seen policy. 178 There is no implied ordering of "id" fields between revisions. 180 An example TXT record is as below: 182 "_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"" 184 The formal definition of the "_mta-sts" TXT record, defined using 185 [RFC5234], is as follows: 187 sts-text-record = sts-version *WSP field-delim *WSP sts-id 188 [field-delim [sts-extensions]] 190 field-delim = %x3B ; ";" 192 sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" 193 %x53 %x76 %x31 195 sts-id = %x69 %x64 *WSP "=" 196 *WSP 1*32(ALPHA / DIGIT) ; "id=" 198 sts-extensions = sts-extension *(field-delim sts-extension) 199 [field-delim] ; extension fields 201 sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value 203 sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") 205 sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding 206 ; "=", ";", SP, and 207 ; control chars 209 If multiple TXT records for "_mta-sts" are returned by the resolver, 210 records which do not begin with "v=STSv1;" are discarded. If the 211 number of resulting records is not one, senders MUST assume the 212 recipient domain does not implement MTA-STS and skip the remaining 213 steps of policy discovery. 215 3.2. MTA-STS Policies 217 The policy itself is a JSON [RFC7159] object served via the HTTPS GET 218 method from the fixed [RFC5785] "well-known" path of ".well-known/ 219 mta-sts.json" served by the "mta-sts" host at the Policy Domain. 220 Thus for "example.com" the path is "https://mta-sts.example.com 221 /.well-known/mta-sts.json". 223 This JSON object contains the following key/value pairs: 225 o "version": (plain-text, required). Currently only "STSv1" is 226 supported. 228 o "mode": (plain-text, required). Either "enforce" or "report", 229 indicating the expected behavior of a sending MTA in the case of a 230 policy validation failure. 232 o "max_age": Max lifetime of the policy (plain-text non-negative 233 integer seconds, required). Well-behaved clients SHOULD cache a 234 policy for up to this value from last policy fetch time. To 235 mitigate the risks of attacks at policy refresh time, it is 236 expected that this value typically be in the range of weeks or 237 greater. 239 o "mx": MX identity patterns (list of plain-text strings, required). 240 One or more patterns matching a Common Name ([RFC6125]) or Subject 241 Alternative Name ([RFC5280]) DNS-ID present in the X.509 242 certificate presented by any MX receiving mail for this domain. 243 For example, "["mail.example.com", ".example.net"]" indicates that 244 mail for this domain might be handled by any MX with a certificate 245 valid for a host at "mail.example.com" or "example.net". Valid 246 patterns can be either fully specified names ("example.com") or 247 suffixes (".example.net") matching the right-hand parts of a 248 server's identity; the latter case are distinguished by a leading 249 period. In the case of Internationalized Domain Names 250 ([RFC5891]), the MX MUST specify the Punycode-encoded A-label 251 [RFC3492] and not the Unicode-encoded U-label. The full semantics 252 of certificate validation are described in Section 4.1, "MX 253 Certificate Validation." 255 An example JSON policy is as below: 257 { 258 "version": "STSv1", 259 "mode": "enforce", 260 "mx": [".mail.example.com"], 261 "max_age": 123456 262 } 264 Parsers MUST accept TXT records and policy files which are 265 syntactically valid (i.e. valid key-value pairs separated by semi- 266 colons for TXT records and valid JSON for policy files) and 267 implementing a superset of this specification, in which case unknown 268 fields SHALL be ignored. 270 3.3. HTTPS Policy Fetching 272 When fetching a new policy or updating a policy, the HTTPS endpoint 273 MUST present a X.509 certificate which is valid for the "mta-sts" 274 host (as described below), chain to a root CA that is trusted by the 275 sending MTA, and be non-expired. It is expected that sending MTAs 276 use a set of trusted CAs similar to those in widely deployed Web 277 browsers and operating systems. 279 The certificate is valid for the "mta-sts" host with respect to the 280 rules described in [RFC6125], with the following application-specific 281 considerations: 283 o Matching is performed only against the DNS-ID and CN-ID 284 identifiers. 286 o DNS domain names in server certificates MAY contain the wildcard 287 character '*' as the complete left-most label within the 288 identifier. 290 The certificate MAY be checked for revocation via the Online 291 Certificate Status Protocol (OCSP) [RFC2560], certificate revocation 292 lists (CRLs), or some other mechanism. 294 HTTP 3xx redirects MUST NOT be followed. 296 Senders may wish to rate-limit the frequency of attempts to fetch the 297 HTTPS endpoint even if a valid TXT record for the recipient domain 298 exists. In the case that the HTTPS GET fails, we suggest 299 implementions may limit further attempts to a period of five minutes 300 or longer per version ID, to avoid overwhelming resource-constrained 301 recipients with cascading failures. 303 Senders MAY impose a timeout on the HTTPS GET and/or a limit on the 304 maximum size of the response body to avoid long delays or resource 305 exhaustion during attempted policy updates. A suggested timeout is 306 one minute, and a suggested maximum policy size 64 kilobytes; policy 307 hosts SHOULD respond to requests with a complete policy body within 308 that timeout and size limit. 310 If a valid TXT record is found but no policy can be fetched via HTTPS 311 (for any reason), and there is no valid (non-expired) previously- 312 cached policy, senders MUST continue with delivery as though the 313 domain has not implemented MTA-STS. Senders who implement TLSRPT 314 (TODO: add ref) should, however, report this failure to the recipient 315 domain if the domain implements TLSRPT as well. 317 Conversely, if no "live" policy can be discovered via DNS or fetched 318 via HTTPS, but a valid (non-expired) policy exists in the sender's 319 cache, the sender MUST apply that cached policy. 321 3.4. Policy Selection for Smart Hosts and Subdomains 323 When sending mail via a "smart host"--an intermediate SMTP relay 324 rather than the message recipient's server--compliant senders MUST 325 treat the smart host domain as the policy domain for the purposes of 326 policy discovery and application. 328 When sending mail to a mailbox at a subdomain, compliant senders MUST 329 NOT attempt to fetch a policy from the parent zone. Thus for mail 330 sent to "user@mail.example.com", the policy can be fetched only from 331 "mail.example.com", not "example.com". 333 4. Policy Validation 335 When sending to an MX at a domain for which the sender has a valid 336 and non-expired MTA-STS policy, a sending MTA honoring MTA-STS MUST 337 validate: 339 1. That the recipient MX supports STARTTLS and offers a valid PKIX- 340 based TLS certificate. 342 2. That at least one of the policy's "mx" patterns matches at least 343 one of the identities presented in the MX's X.509 certificate, as 344 described in "MX Certificate Validation". 346 This section does not dictate the behavior of sending MTAs when 347 policies fail to validate; in particular, validation failures of 348 policies which specify "report" mode MUST NOT be interpreted as 349 delivery failures, as described in Section 5, "Policy Application". 351 4.1. MX Certificate Validation 353 The certificate presented by the receiving MX MUST chain to a root CA 354 that is trusted by the sending MTA and be non-expired. The 355 certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a 356 DNS-ID matching the "mx" pattern. The MX's certificate MAY also be 357 checked for revocation via OCSP [RFC2560], certificate revocation 358 lists (CRLs), or some other mechanism. 360 Because the "mx" patterns are not hostnames, however, matching is not 361 identical to other common cases of X.509 certificate authentication 362 (as described, for example, in [RFC6125]). Consider the example 363 policy given above, with an "mx" pattern containing ".example.net". 364 In this case, if the MX server's X.509 certificate contains a SAN 365 matching "*.example.net", we are required to implement "wildcard-to- 366 wildcard" matching. 368 To simplify this case, we impose the following constraints on 369 wildcard certificates, identical to those in [RFC7672] section 3.2.3 370 and [@!RFC6125 section 6.4.3: wildcards are valid in DNS-IDs or CN- 371 IDs, but must be the entire first label of the identifier (that is, 372 "*.example.com", not "mail*.example.com"). Senders who are comparing 373 a "suffix" MX pattern with a wildcard identifier should thus strip 374 the wildcard and ensure that the two sides match label-by-label, 375 until all labels of the shorter side (if unequal length) are 376 consumed. 378 A simple pseudocode implementation of this algorithm is presented in 379 the Appendix. 381 5. Policy Application 383 When sending to an MX at a domain for which the sender has a valid, 384 non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies 385 the result of a policy validation failure one of two ways, depending 386 on the value of the policy "mode" field: 388 1. "report": In this mode, sending MTAs merely send a report (as 389 described in the TLSRPT specification (TODO: add ref)) indicating 390 policy application failures. 392 2. "enforce": In this mode, sending MTAs MUST NOT deliver the 393 message to hosts which fail MX matching or certificate 394 validation. 396 When a message fails to deliver due to an "enforce" policy, a 397 compliant MTA MUST NOT permanently fail to deliver messages before 398 checking for the presence of an updated policy at the Policy Domain. 399 (In all cases, MTAs SHOULD treat such failures as transient errors 400 and retry delivery later.) This allows implementing domains to 401 update long-lived policies on the fly. 403 Finally, in both "enforce" and "report" modes, failures to deliver in 404 compliance with the applied policy result in failure reports to the 405 policy domain, as described in the TLSRPT specification (TODO: add 406 ref). 408 5.1. Policy Application Control Flow 410 An example control flow for a compliant sender consists of the 411 following steps: 413 1. Check for a cached policy whose time-since-fetch has not exceeded 414 its "max_age". If none exists, attempt to fetch a new policy 415 (perhaps asynchronously, so as not to block message delivery). 416 Optionally, sending MTAs may unconditionally check for a new 417 policy at this step. 419 2. For each candidate MX, in order of MX priority, attempt to 420 deliver the message, enforcing STARTTLS and, assuming a policy is 421 present, PKIX certificate validation as described in Section 4.1, 422 "MX Certificate Validation." 424 3. A message delivery MUST NOT be permanently failed until the 425 sender has first checked for the presence of a new policy (as 426 indicated by the "id" field in the "_mta-sts" TXT record). If a 427 new policy is not found, senders SHOULD apply existing rules for 428 the case of temporary message delivery failures (as discussed in 429 [RFC5321] section 4.5.4.1). 431 6. Operational Considerations 433 6.1. Policy Updates 435 Updating the policy requires that the owner make changes in two 436 places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and 437 at the corresponding HTTPS endpoint. As a result, recipients should 438 expect a policy will continue to be used by senders until both the 439 HTTPS and TXT endpoints are updated and the TXT record's TTL has 440 passed. 442 In other words, a sender who is unable to successfully deliver a 443 message while applying a cache of the recipient's now-outdated policy 444 may be unable to discover that a new policy exists until the DNS TTL 445 has passed. Recipients should therefore ensure that old policies 446 continue to work for message delivery during this period of time, or 447 risk message delays. 449 Recipients should also prefer to update the HTTPS policy body before 450 updating the TXT record; this ordering avoids the risk that senders, 451 seeing a new TXT record, mistakenly cache the old policy from HTTPS. 453 7. IANA Considerations 455 A new .well-known URI will be registered in the Well-Known URIs 456 registry as described below: 458 URI Suffix: mta-sts.json Change Controller: IETF 460 8. Security Considerations 462 SMTP MTA Strict Transport Security attempts to protect against an 463 active attacker who wishes to intercept or tamper with mail between 464 hosts who support STARTTLS. There are two classes of attacks 465 considered: 467 o Foiling TLS negotiation, for example by deleting the "250 468 STARTTLS" response from a server or altering TLS session 469 negotiation. This would result in the SMTP session occurring over 470 plaintext, despite both parties supporting TLS. 472 o Impersonating the destination mail server, whereby the sender 473 might deliver the message to an impostor, who could then monitor 474 and/or modify messages despite opportunistic TLS. This 475 impersonation could be accomplished by spoofing the DNS MX record 476 for the recipient domain, or by redirecting client connections 477 intended for the legitimate recipient server (for example, by 478 altering BGP routing tables). 480 MTA-STS can thwart such attacks only if the sender is able to 481 previously obtain and cache a policy for the recipient domain, and 482 only if the attacker is unable to obtain a valid certificate that 483 complies with that policy. Below, we consider specific attacks on 484 this model. 486 8.1. Obtaining a Signed Certificate 488 SMTP MTA-STS relies on certificate validation via PKIX based TLS 489 identity checking [RFC6125]. Attackers who are able to obtain a 490 valid certificate for the targeted recipient mail service (e.g. by 491 compromising a certificate authority) are thus able to circumvent STS 492 authentication. 494 8.2. Preventing Policy Discovery 496 Since MTA-STS uses DNS TXT records for policy discovery, an attacker 497 who is able to block DNS responses can suppress the discovery of an 498 MTA-STS Policy, making the Policy Domain appear not to have an MTA- 499 STS Policy. The sender policy cache is designed to resist this 500 attack by decreasing the frequency of policy discovery and thus 501 reducing the window of vulnerability; it is nonetheless a risk that 502 attackers who can predict or induce policy discovery--for example, by 503 inducing a victim sending domain to send mail to a never-before- 504 contacted recipient while carrying out a man-in-the-middle attack-- 505 may be able to foil policy discovery and effectively downgrade the 506 security of the message delivery. 508 Since this attack depends upon intercepting initial policy discovery, 509 we strongly recommend implementors to prefer policy "max_age" values 510 to be as long as is practical. 512 Because this attack is also possible upon refresh of a cached policy, 513 we suggest implementors do not wait until a cached policy has expired 514 before checking for an update; if senders attempt to refresh the 515 cache regularly (for instance, by checking their cached version 516 string against the TXT record on each successful send, or in a 517 background task that runs daily or weekly), an attacker would have to 518 foil policy discovery consistently over the lifetime of a cached 519 policy to prevent a successful refresh. 521 Resistence to downgrade attacks of this nature--due to the ability to 522 authoritatively determine "lack of a record" even for non- 523 participating recipients--is a feature of DANE, due to its use of 524 DNSSEC for policy discovery. 526 8.3. Denial of Service 528 We additionally consider the Denial of Service risk posed by an 529 attacker who can modify the DNS records for a victim domain. Absent 530 MTA-STS, such an attacker can cause a sending MTA to cache invalid MX 531 records, but only for however long the sending resolver caches those 532 records. With MTA-STS, the attacker can additionally advertise a 533 new, long-"max_age" MTA-STS policy with "mx" constraints that 534 validate the malicious MX record, causing senders to cache the policy 535 and refuse to deliver messages once the victim has resecured the MX 536 records. 538 This attack is mitigated in part by the ability of a victim domain to 539 (at any time) publish a new policy updating the cached, malicious 540 policy, though this does require the victim domain to both obtain a 541 valid CA-signed certificate and to understand and properly configure 542 MTA-STS. 544 Similarly, we consider the possibility of domains that deliberately 545 allow untrusted users to serve untrusted content on user-specified 546 subdomains. In some cases (e.g. the service Tumblr.com) this takes 547 the form of providing HTTPS hosting of user-registered subdomains; in 548 other cases (e.g. dynamic DNS providers) this takes the form of 549 allowing untrusted users to register custom DNS records at the 550 provider's domain. 552 In these cases, there is a risk that untrusted users would be able to 553 serve custom content at the "mta-sts" host, including serving an 554 illegitimate MTA-STS policy. We believe this attack is rendered more 555 difficult by the need for the attacker to also serve the "_mta-sts" 556 TXT record on the same domain--something not, to our knowledge, 557 widely provided to untrusted users. This attack is additionally 558 mitigated by the aforementioned ability for a victim domain to update 559 an invalid policy at any future date. 561 8.4. Weak Policy Constraints 563 Even if an attacker cannot modify a served policy, the potential 564 exists for configurations that allow attackers on the same domain to 565 receive mail for that domain. For example, an easy configuration 566 option when authoring an MTA-STS Policy for "example.com" is to set 567 the "mx" equal to ".example.com"; recipient domains must consider in 568 this case the risk that any user possessing a valid hostname and CA- 569 signed certificate (for example, "dhcp-123.example.com") will, from 570 the perspective of MTA-STS Policy validation, be a valid MX host for 571 that domain. 573 9. Contributors 575 Nicolas Lidzborski Google, Inc nlidz (at) google (dot com) 577 Wei Chuang Google, Inc weihaw (at) google (dot com) 579 Brandon Long Google, Inc blong (at) google (dot com) 581 Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com) 583 Klaus Umbach 1&1 Mail & Media Development & Technology GmbH 584 klaus.umbach (at) 1und1 (dot de) 586 Markus Laber 1&1 Mail & Media Development & Technology GmbH 587 markus.laber (at) 1und1 (dot de) 589 10. Appendix 1: MTA-STS example record & policy 591 The owner of "example.com" wishes to begin using MTA-STS with a 592 policy that will solicit reports from senders without affecting how 593 the messages are processed, in order to verify the identity of MXs 594 that handle mail for "example.com", confirm that TLS is correctly 595 used, and ensure that certificates presented by the recipient MX 596 validate. 598 MTA-STS policy indicator TXT RR: 600 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 602 MTA-STS Policy JSON served as the response body at [1] 604 { 605 "version": "STSv1", 606 "mode": "report", 607 "mx": ["mx1.example.com", "mx2.example.com"], 608 "max_age": 12345678 609 } 611 11. Appendix 2: Message delivery pseudocode 613 Below is pseudocode demonstrating the logic of a compliant sending 614 MTA. 616 While this pseudocode implementation suggests synchronous policy 617 retrieval in the delivery path, in a working implementation that may 618 be undesirable, and we expect some implementors to instead prefer a 619 background fetch that does not block delivery if no cached policy is 620 present. 622 func isEnforce(policy) { 623 // Return true if the policy mode is "enforce". 624 } 626 func isNonExpired(policy) { 627 // Return true if the policy is not expired. 628 } 630 func tryStartTls(connection) { 631 // Attempt to open an SMTP connection with STARTTLS with the MX. 632 } 634 func certMatches(connection, policy) { 635 // Assume a handy function to return CN and DNS-ID SANs. 636 for san in getDnsIdSansAndCnFromCert(connection) { 637 for mx in policy.mx { 638 // Return if the server certificate from "connection" matches the "mx" host. 639 if san[0] == '*' { 640 // Invalid wildcard! 641 if san[1] != '.' continue 642 san = san[1:] 643 } 644 if san[0] == '.' && HasSuffix(mx, san) { 645 return true 646 } 647 if mx[0] == '.' && HasSuffix(san, mx) { 648 return true 649 } 650 if mx == san { 651 return true 652 } 653 } 654 } 655 return false 656 } 658 func tryDeliverMail(connection, message) { 659 // Attempt to deliver "message" via "connection". 660 } 662 func tryGetNewPolicy(domain) { 663 // Check for an MTA-STS TXT record for "domain" in DNS, and return the 664 // indicated policy. 665 } 667 func cachePolicy(domain, policy) { 668 // Store "policy" as the cached policy for "domain". 669 } 671 func tryGetCachedPolicy(domain) { 672 // Return a cached policy for "domain". 673 } 675 func reportError(error) { 676 // Report an error via TLSRPT. 677 } 679 func tryMxAccordingTo(message, mx, policy) { 680 connection := connect(mx) 681 if !connection { 682 return false // Can't connect to the MX so it's not an MTA-STS error. 683 } 684 secure := true 685 if !tryStartTls(connection) { 686 secure = false 687 reportError(E_NO_VALID_TLS) 688 } else if !certMatches(connection, policy) { 689 secure = false 690 reportError(E_CERT_MISMATCH) 691 } 692 if secure || !isEnforce(policy) { 693 return tryDeliverMail(connection, message) 694 } 695 return false 696 } 698 func tryWithPolicy(message, domain, policy) { 699 mxes := getMxForDomain(domain) 700 for mx in mxes { 701 if tryMxAccordingTo(message, mx, policy) { 702 return true 703 } 704 } 705 return false 706 } 708 func handleMessage(message) { 709 domain := ... // domain part after '@' from recipient 710 policy := tryGetNewPolicy(domain) 711 if policy { 712 cachePolicy(domain, policy) 713 } else { 714 policy = tryGetCachedPolicy(domain) 715 } 716 if policy { 717 return tryWithPolicy(message, domain, policy) 718 } 719 // Try to deliver the message normally (i.e. without MTA-STS). 720 } 722 12. References 724 12.1. Normative References 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 728 RFC2119, March 1997, 729 . 731 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 732 Adams, "X.509 Internet Public Key Infrastructure Online 733 Certificate Status Protocol - OCSP", RFC 2560, DOI 10 734 .17487/RFC2560, June 1999, 735 . 737 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 738 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 739 February 2002, . 741 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 742 for Internationalized Domain Names in Applications 743 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 744 . 746 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 747 Rose, "DNS Security Introduction and Requirements", RFC 748 4033, DOI 10.17487/RFC4033, March 2005, 749 . 751 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 752 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 753 RFC5234, January 2008, 754 . 756 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 757 Housley, R., and W. Polk, "Internet X.509 Public Key 758 Infrastructure Certificate and Certificate Revocation List 759 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 760 . 762 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 763 DOI 10.17487/RFC5321, October 2008, 764 . 766 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 767 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10 768 .17487/RFC5785, April 2010, 769 . 771 [RFC5891] Klensin, J., "Internationalized Domain Names in 772 Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ 773 RFC5891, August 2010, 774 . 776 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 777 Verification of Domain-Based Application Service Identity 778 within Internet Public Key Infrastructure Using X.509 779 (PKIX) Certificates in the Context of Transport Layer 780 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 781 2011, . 783 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 784 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 785 2014, . 787 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 788 Opportunistic DNS-Based Authentication of Named Entities 789 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10 790 .17487/RFC7672, October 2015, 791 . 793 12.2. URIs 795 [1] https://mta-sts.example.com/.well-known/mta-sts.json: 797 Authors' Addresses 799 Daniel Margolis 800 Google, Inc 802 Email: dmargolis (at) google.com 803 Mark Risher 804 Google, Inc 806 Email: risher (at) google (dot com) 808 Binu Ramakrishnan 809 Yahoo!, Inc 811 Email: rbinu (at) yahoo-inc (dot com) 813 Alexander Brotman 814 Comcast, Inc 816 Email: alex_brotman (at) comcast.com 818 Janet Jones 819 Microsoft, Inc 821 Email: janet.jones (at) microsoft (dot com)