idnits 2.17.1 draft-ietf-uta-mta-sts-05.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 3, 2017) is 2522 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 791 -- Looks like a reference, but probably isn't: '0' on line 643 ** 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: November 4, 2017 B. Ramakrishnan 6 Yahoo!, Inc 7 A. Brotman 8 Comcast, Inc 9 J. Jones 10 Microsoft, Inc 11 May 3, 2017 13 SMTP MTA Strict Transport Security (MTA-STS) 14 draft-ietf-uta-mta-sts-05 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 4, 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 thus expect a policy will continue to be used by senders until both 439 the 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 7. IANA Considerations 451 A new .well-known URI will be registered in the Well-Known URIs 452 registry as described below: 454 URI Suffix: mta-sts.json Change Controller: IETF 456 8. Security Considerations 458 SMTP MTA Strict Transport Security attempts to protect against an 459 active attacker who wishes to intercept or tamper with mail between 460 hosts who support STARTTLS. There are two classes of attacks 461 considered: 463 o Foiling TLS negotiation, for example by deleting the "250 464 STARTTLS" response from a server or altering TLS session 465 negotiation. This would result in the SMTP session occurring over 466 plaintext, despite both parties supporting TLS. 468 o Impersonating the destination mail server, whereby the sender 469 might deliver the message to an impostor, who could then monitor 470 and/or modify messages despite opportunistic TLS. This 471 impersonation could be accomplished by spoofing the DNS MX record 472 for the recipient domain, or by redirecting client connections 473 intended for the legitimate recipient server (for example, by 474 altering BGP routing tables). 476 MTA-STS can thwart such attacks only if the sender is able to 477 previously obtain and cache a policy for the recipient domain, and 478 only if the attacker is unable to obtain a valid certificate that 479 complies with that policy. Below, we consider specific attacks on 480 this model. 482 8.1. Obtaining a Signed Certificate 484 SMTP MTA-STS relies on certificate validation via PKIX based TLS 485 identity checking [RFC6125]. Attackers who are able to obtain a 486 valid certificate for the targeted recipient mail service (e.g. by 487 compromising a certificate authority) are thus able to circumvent STS 488 authentication. 490 8.2. Preventing Policy Discovery 492 Since MTA-STS uses DNS TXT records for policy discovery, an attacker 493 who is able to block DNS responses can suppress the discovery of an 494 MTA-STS Policy, making the Policy Domain appear not to have an MTA- 495 STS Policy. The sender policy cache is designed to resist this 496 attack by decreasing the frequency of policy discovery and thus 497 reducing the window of vulnerability; it is nonetheless a risk that 498 attackers who can predict or induce policy discovery--for example, by 499 inducing a victim sending domain to send mail to a never-before- 500 contacted recipient while carrying out a man-in-the-middle attack-- 501 may be able to foil policy discovery and effectively downgrade the 502 security of the message delivery. 504 Since this attack depends upon intercepting initial policy discovery, 505 we strongly recommend implementors to prefer policy "max_age" values 506 to be as long as is practical. 508 Because this attack is also possible upon refresh of a cached policy, 509 we suggest implementors do not wait until a cached policy has expired 510 before checking for an update; if senders attempt to refresh the 511 cache regularly (for instance, by checking their cached version 512 string against the TXT record on each successful send, or in a 513 background task that runs daily or weekly), an attacker would have to 514 foil policy discovery consistently over the lifetime of a cached 515 policy to prevent a successful refresh. 517 Resistence to downgrade attacks of this nature--due to the ability to 518 authoritatively determine "lack of a record" even for non- 519 participating recipients--is a feature of DANE, due to its use of 520 DNSSEC for policy discovery. 522 8.3. Denial of Service 524 We additionally consider the Denial of Service risk posed by an 525 attacker who can modify the DNS records for a victim domain. Absent 526 MTA-STS, such an attacker can cause a sending MTA to cache invalid MX 527 records, but only for however long the sending resolver caches those 528 records. With MTA-STS, the attacker can additionally advertise a 529 new, long-"max_age" MTA-STS policy with "mx" constraints that 530 validate the malicious MX record, causing senders to cache the policy 531 and refuse to deliver messages once the victim has resecured the MX 532 records. 534 This attack is mitigated in part by the ability of a victim domain to 535 (at any time) publish a new policy updating the cached, malicious 536 policy, though this does require the victim domain to both obtain a 537 valid CA-signed certificate and to understand and properly configure 538 MTA-STS. 540 Similarly, we consider the possibility of domains that deliberately 541 allow untrusted users to serve untrusted content on user-specified 542 subdomains. In some cases (e.g. the service Tumblr.com) this takes 543 the form of providing HTTPS hosting of user-registered subdomains; in 544 other cases (e.g. dynamic DNS providers) this takes the form of 545 allowing untrusted users to register custom DNS records at the 546 provider's domain. 548 In these cases, there is a risk that untrusted users would be able to 549 serve custom content at the "mta-sts" host, including serving an 550 illegitimate MTA-STS policy. We believe this attack is rendered more 551 difficult by the need for the attacker to also serve the "_mta-sts" 552 TXT record on the same domain--something not, to our knowledge, 553 widely provided to untrusted users. This attack is additionally 554 mitigated by the aforementioned ability for a victim domain to update 555 an invalid policy at any future date. 557 8.4. Weak Policy Constraints 559 Even if an attacker cannot modify a served policy, the potential 560 exists for configurations that allow attackers on the same domain to 561 receive mail for that domain. For example, an easy configuration 562 option when authoring an MTA-STS Policy for "example.com" is to set 563 the "mx" equal to ".example.com"; recipient domains must consider in 564 this case the risk that any user possessing a valid hostname and CA- 565 signed certificate (for example, "dhcp-123.example.com") will, from 566 the perspective of MTA-STS Policy validation, be a valid MX host for 567 that domain. 569 9. Contributors 571 Nicolas Lidzborski Google, Inc nlidz (at) google (dot com) 573 Wei Chuang Google, Inc weihaw (at) google (dot com) 575 Brandon Long Google, Inc blong (at) google (dot com) 577 Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com) 579 Klaus Umbach 1&1 Mail & Media Development & Technology GmbH 580 klaus.umbach (at) 1und1 (dot de) 582 Markus Laber 1&1 Mail & Media Development & Technology GmbH 583 markus.laber (at) 1und1 (dot de) 585 10. Appendix 1: MTA-STS example record & policy 587 The owner of "example.com" wishes to begin using MTA-STS with a 588 policy that will solicit reports from senders without affecting how 589 the messages are processed, in order to verify the identity of MXs 590 that handle mail for "example.com", confirm that TLS is correctly 591 used, and ensure that certificates presented by the recipient MX 592 validate. 594 MTA-STS policy indicator TXT RR: 596 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 598 MTA-STS Policy JSON served as the response body at [1] 600 { 601 "version": "STSv1", 602 "mode": "report", 603 "mx": ["mx1.example.com", "mx2.example.com"], 604 "max_age": 12345678 605 } 607 11. Appendix 2: Message delivery pseudocode 609 Below is pseudocode demonstrating the logic of a compliant sending 610 MTA. 612 While this pseudocode implementation suggests synchronous policy 613 retrieval in the delivery path, in a working implementation that may 614 be undesirable, and we expect some implementors to instead prefer a 615 background fetch that does not block delivery if no cached policy is 616 present. 618 func isEnforce(policy) { 619 // Return true if the policy mode is "enforce". 620 } 622 func isNonExpired(policy) { 623 // Return true if the policy is not expired. 624 } 626 func tryStartTls(connection) { 627 // Attempt to open an SMTP connection with STARTTLS with the MX. 628 } 630 func certMatches(connection, policy) { 631 // Assume a handy function to return CN and DNS-ID SANs. 632 for san in getDnsIdSansAndCnFromCert(connection) { 633 for mx in policy.mx { 634 // Return if the server certificate from "connection" matches the "mx" host. 635 if san[0] == '*' { 636 // Invalid wildcard! 637 if san[1] != '.' return false 638 san = san[1:] 639 } 640 if san[0] == '.' && HasSuffix(mx, san) { 641 return true 642 } 643 if mx[0] == '.' && HasSuffix(san, mx) { 644 return true 645 } 646 if mx == san { 647 return true 648 } 649 } 650 } 651 return false 652 } 654 func tryDeliverMail(connection, message) { 655 // Attempt to deliver "message" via "connection". 656 } 658 func tryGetNewPolicy(domain) { 659 // Check for an MTA-STS TXT record for "domain" in DNS, and return the 660 // indicated policy. 661 } 662 func cachePolicy(domain, policy) { 663 // Store "policy" as the cached policy for "domain". 664 } 666 func tryGetCachedPolicy(domain) { 667 // Return a cached policy for "domain". 668 } 670 func reportError(error) { 671 // Report an error via TLSRPT. 672 } 674 func tryMxAccordingTo(message, mx, policy) { 675 connection := connect(mx) 676 if !connection { 677 return false // Can't connect to the MX so it's not an MTA-STS error. 678 } 679 secure := true 680 if !tryStartTls(connection) { 681 secure = false 682 reportError(E_NO_VALID_TLS) 683 } else if !certMatches(connection, policy) { 684 secure = false 685 reportError(E_CERT_MISMATCH) 686 } 687 if secure || !isEnforce(policy) { 688 return tryDeliverMail(connection, message) 689 } 690 return false 691 } 693 func tryWithPolicy(message, domain, policy) { 694 mxes := getMxForDomain(domain) 695 for mx in mxes { 696 if tryMxAccordingTo(message, mx, policy) { 697 return true 698 } 699 } 700 return false 701 } 703 func handleMessage(message) { 704 domain := ... // domain part after '@' from recipient 705 policy := tryGetNewPolicy(domain) 706 if policy { 707 cachePolicy(domain, policy) 708 } else { 709 policy = tryGetCachedPolicy(domain) 711 } 712 if policy { 713 return tryWithPolicy(message, domain, policy) 714 } 715 // Try to deliver the message normally (i.e. without MTA-STS). 716 } 718 12. References 720 12.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 724 RFC2119, March 1997, 725 . 727 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 728 Adams, "X.509 Internet Public Key Infrastructure Online 729 Certificate Status Protocol - OCSP", RFC 2560, DOI 10 730 .17487/RFC2560, June 1999, 731 . 733 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 734 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 735 February 2002, . 737 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 738 for Internationalized Domain Names in Applications 739 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 740 . 742 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 743 Rose, "DNS Security Introduction and Requirements", RFC 744 4033, DOI 10.17487/RFC4033, March 2005, 745 . 747 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 748 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 749 RFC5234, January 2008, 750 . 752 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 753 Housley, R., and W. Polk, "Internet X.509 Public Key 754 Infrastructure Certificate and Certificate Revocation List 755 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 756 . 758 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 759 DOI 10.17487/RFC5321, October 2008, 760 . 762 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 763 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10 764 .17487/RFC5785, April 2010, 765 . 767 [RFC5891] Klensin, J., "Internationalized Domain Names in 768 Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ 769 RFC5891, August 2010, 770 . 772 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 773 Verification of Domain-Based Application Service Identity 774 within Internet Public Key Infrastructure Using X.509 775 (PKIX) Certificates in the Context of Transport Layer 776 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 777 2011, . 779 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 780 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 781 2014, . 783 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 784 Opportunistic DNS-Based Authentication of Named Entities 785 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10 786 .17487/RFC7672, October 2015, 787 . 789 12.2. URIs 791 [1] https://mta-sts.example.com/.well-known/mta-sts.json: 793 Authors' Addresses 795 Daniel Margolis 796 Google, Inc 798 Email: dmargolis (at) google.com 800 Mark Risher 801 Google, Inc 803 Email: risher (at) google (dot com) 804 Binu Ramakrishnan 805 Yahoo!, Inc 807 Email: rbinu (at) yahoo-inc (dot com) 809 Alexander Brotman 810 Comcast, Inc 812 Email: alex_brotman (at) comcast.com 814 Janet Jones 815 Microsoft, Inc 817 Email: janet.jones (at) microsoft (dot com)