idnits 2.17.1 draft-ietf-uta-mta-sts-04.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 8 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 (April 3, 2017) is 2572 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 736 -- Looks like a reference, but probably isn't: '0' on line 598 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 4 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: October 5, 2017 B. Ramakrishnan 6 Yahoo!, Inc 7 A. Brotman 8 Comcast, Inc 9 J. Jones 10 Microsoft, Inc 11 April 3, 2017 13 SMTP MTA Strict Transport Security (MTA-STS) 14 draft-ietf-uta-mta-sts-04 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 October 5, 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 . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 7 68 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Policy Application Control Flow . . . . . . . . . . . . . 8 70 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 71 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 10 75 8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 10 76 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 77 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 11 78 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 12 80 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 12 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 "Policy Selection for Smart Hosts"). 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 the 134 section "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 %x3B *WSP sts-id [%x3B] 189 sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" 190 %x53 %x76 %x31 192 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) 194 If multiple TXT records for "_mta-sts" are returned by the resolver, 195 records which do not begin with "v=STSv1;" are discarded. If the 196 number of resulting records is not one, senders MUST assume the 197 recipient domain does not implement MTA-STS and skip the remaining 198 steps of policy discovery. 200 3.2. MTA-STS Policies 202 The policy itself is a JSON [RFC4627] object served via the HTTPS GET 203 method from the fixed [RFC5785] "well-known" path of ".well-known/ 204 mta-sts.json" served by the "mta-sts" host at the Policy Domain. 205 Thus for "example.com" the path is "https://mta-sts.example.com 206 /.well-known/mta-sts.json". 208 This JSON object contains the following key/value pairs: 210 o "version": (plain-text, required). Currently only "STSv1" is 211 supported. 213 o "mode": (plain-text, required). Either "enforce" or "report", 214 indicating the expected behavior of a sending MTA in the case of a 215 policy validation failure. 217 o "max_age": Max lifetime of the policy (plain-text non-negative 218 integer seconds, required). Well-behaved clients SHOULD cache a 219 policy for up to this value from last policy fetch time. To 220 mitigate the risks of attacks at policy refresh time, it is 221 expected that this value typically be in the range of weeks or 222 greater. 224 o "mx": MX identity patterns (list of plain-text strings, required). 225 One or more patterns matching a Common Name ([RFC6125]) or Subject 226 Alternative Name ([RFC5280]) DNS-ID present in the X.509 227 certificate presented by any MX receiving mail for this domain. 228 For example, "["mail.example.com", ".example.net"]" indicates that 229 mail for this domain might be handled by any MX with a certificate 230 valid for a host at "example.com" or "example.net". Valid 231 patterns can be either fully specified names ("example.com") or 232 suffixes (".example.net") matching the right-hand parts of a 233 server's identity; the latter case are distinguished by a leading 234 period. In the case of Internationalized Domain Names 235 ([RFC5891]), the MX MUST specify the Punycode-encoded A-label 236 [RFC3492] and not the Unicode-encoded U-label. The full semantics 237 of certificate validation are described in "MX Certificate 238 Validation." 240 An example JSON policy is as below: 242 { 243 "version": "STSv1", 244 "mode": "enforce", 245 "mx": [".mail.example.com"], 246 "max_age": 123456 247 } 249 Parsers SHOULD accept TXT records and policy files which are 250 syntactically valid (i.e. valid key-value pairs separated by semi- 251 colons for TXT records and valid JSON for policy files) and 252 implementing a superset of this specification, in which case unknown 253 fields SHALL be ignored. 255 3.3. HTTPS Policy Fetching 257 When fetching a new policy or updating a policy, the HTTPS endpoint 258 MUST present a X.509 certificate which is valid for the "mta-sts" 259 host (as described in [RFC6125]), chain to a root CA that is trusted 260 by the sending MTA, and be non-expired. It is expected that sending 261 MTAs use a set of trusted CAs similar to those in widely deployed Web 262 browsers and operating systems. 264 HTTP 3xx redirects MUST NOT be followed. 266 Senders may wish to rate-limit the frequency of attempts to fetch the 267 HTTPS endpoint even if a valid TXT record for the recipient domain 268 exists. In the case that the HTTPS GET fails, we suggest 269 implementions may limit further attempts to a period of five minutes 270 or longer per version ID, to avoid overwhelming resource-constrained 271 recipients with cascading failures. 273 Senders MAY impose a timeout on the HTTPS GET to avoid long delays 274 imposed by attempted policy updates. A suggested timeout is one 275 minute; policy hosts SHOULD respond to requests with a complete 276 policy body within that timeout. 278 If a valid TXT record is found but no policy can be fetched via 279 HTTPS, and there is no valid (non-expired) previously-cached policy, 280 senders MUST treat the recipient domain as one that has not 281 implemented MTA-STS. 283 3.4. Policy Selection for Smart Hosts and Subdomains 285 When sending mail via a "smart host"--an intermediate SMTP relay 286 rather than the message recipient's server--compliant senders MUST 287 treat the smart host domain as the policy domain for the purposes of 288 policy discovery and application. 290 When sending mail to a mailbox at a subdomain, compliant senders MUST 291 NOT attempt to fetch a policy from the parent zone. Thus for mail 292 sent to "user@mail.example.com", the policy can be fetched only from 293 "mail.example.com", not "example.com". 295 4. Policy Validation 297 When sending to an MX at a domain for which the sender has a valid 298 and non-expired MTA-STS policy, a sending MTA honoring MTA-STS MUST 299 validate: 301 1. That the recipient MX supports STARTTLS and offers a valid PKIX- 302 based TLS certificate. 304 2. That at least one of the policy's "mx" patterns matches at least 305 one of the identities presented in the MX's X.509 certificate, as 306 descriped in "MX Certificate Validation". 308 This section does not dictate the behavior of sending MTAs when 309 policies fail to validate; in particular, validation failures of 310 policies which specify "report" mode MUST NOT be interpreted as 311 delivery failures, as described in the section "Policy Application". 313 4.1. MX Certificate Validation 315 The certificate presented by the receiving MX MUST chain to a root CA 316 that is trusted by the sending MTA and be non-expired. The 317 certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a 318 DNS-ID matching the "mx" pattern. 320 Because the "mx" patterns are not hostnames, however, matching is not 321 identical to other common cases of X.509 certificate authentication 322 (as described, for example, in [RFC6125]). Consider the example 323 policy given above, with an "mx" pattern containing ".example.net". 324 In this case, if the MX server's X.509 certificate contains a SAN 325 matching "*.example.net", we are required to implement "wildcard-to- 326 wildcard" matching. 328 To simplify this case, we impose the following constraints on 329 wildcard certificates, identical to those in [RFC7672] section 3.2.3: 330 wildcards are valid in DNS-IDs or CN-IDs, but must be the entire 331 first label of the identifier (that is, "*.example.com", not 332 "mail*.example.com"). Senders who are comparing a "suffix" MX 333 pattern with a wildcard identifier should thus strip the wildcard and 334 ensure that the two sides match label-by-label, until all labels of 335 the shorter side (if unequal length) are consumed. 337 A simple pseudocode implementation of this algorithm is presented in 338 the Appendix. 340 5. Policy Application 342 When sending to an MX at a domain for which the sender has a valid, 343 non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies 344 the result of a policy validation failure one of two ways, depending 345 on the value of the policy "mode" field: 347 1. "report": In this mode, sending MTAs merely send a report (as 348 described in the TLSRPT specification (TODO: add ref)) indicating 349 policy application failures. 351 2. "enforce": In this mode, sending MTAs MUST NOT deliver the 352 message to hosts which fail MX matching or certificate 353 validation. 355 When a message fails to deliver due to an "enforce" policy, a 356 compliant MTA MUST NOT permanently fail to deliver messages before 357 checking for the presence of an updated policy at the Policy Domain. 358 (In all cases, MTAs SHOULD treat such failures as transient errors 359 and retry delivery later.) This allows implementing domains to 360 update long-lived policies on the fly. 362 Finally, in both "enforce" and "report" modes, failures to deliver in 363 compliance with the applied policy result in failure reports to the 364 policy domain, as described in the TLSRPT specification (TODO: add 365 ref). 367 5.1. Policy Application Control Flow 369 An example control flow for a compliant sender consists of the 370 following steps: 372 1. Check for a cached policy whose time-since-fetch has not exceeded 373 its "max_age". If none exists, attempt to fetch a new policy 374 (perhaps asynchronously, so as not to block message delivery). 375 Optionally, sending MTAs may unconditionally check for a new 376 policy at this step. 378 2. For each candidate MX, in order of MX priority, attempt to 379 deliver the message, enforcing STARTTLS and, assuming a policy is 380 present, PKIX certificate validation, and certificate validation 381 as described in "MX Certificate Validation." 383 3. Upon message retries, a message MAY be permanently failed 384 following first checking for the presence of a new policy (as 385 indicated by the "id" field in the "_mta-sts" TXT record). 387 6. Operational Considerations 389 6.1. Policy Updates 391 Updating the policy requires that the owner make changes in two 392 places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and 393 at the corresponding HTTPS endpoint. As a result, recipients should 394 thus expect a policy will continue to be used by senders until both 395 the HTTPS and TXT endpoints are updated and the TXT record's TTL has 396 passed. 398 In other words, a sender who is unable to successfully deliver a 399 message while applying a cache of the recipient's now-outdated policy 400 may be unable to discover that a new policy exists until the DNS TTL 401 has passed. Recipients should therefore ensure that old policies 402 continue to work for message delivery during this period of time, or 403 risk message delays. 405 7. IANA Considerations 407 A new .well-known URI will be registered in the Well-Known URIs 408 registry as described below: 410 URI Suffix: mta-sts.json Change Controller: IETF 412 8. Security Considerations 414 SMTP MTA Strict Transport Security attempts to protect against an 415 active attacker who wishes to intercept or tamper with mail between 416 hosts who support STARTTLS. There are two classes of attacks 417 considered: 419 o Foiling TLS negotiation, for example by deleting the "250 420 STARTTLS" response from a server or altering TLS session 421 negotiation. This would result in the SMTP session occurring over 422 plaintext, despite both parties supporting TLS. 424 o Impersonating the destination mail server, whereby the sender 425 might deliver the message to an impostor, who could then monitor 426 and/or modify messages despite opportunistic TLS. This 427 impersonation could be accomplished by spoofing the DNS MX record 428 for the recipient domain, or by redirecting client connections 429 intended for the legitimate recipient server (for example, by 430 altering BGP routing tables). 432 MTA-STS can thwart such attacks only if the sender is able to 433 previously obtain and cache a policy for the recipient domain, and 434 only if the attacker is unable to obtain a valid certificate that 435 complies with that policy. Below, we consider specific attacks on 436 this model. 438 8.1. Obtaining a Signed Certificate 440 SMTP MTA-STS relies on certificate validation via PKIX based TLS 441 identity checking [RFC6125]. Attackers who are able to obtain a 442 valid certificate for the targeted recipient mail service (e.g. by 443 compromising a certificate authority) are thus able to circumvent STS 444 authentication. 446 8.2. Preventing Policy Discovery 448 Since MTA-STS uses DNS TXT records for policy discovery, an attacker 449 who is able to block DNS responses can suppress the discovery of an 450 MTA-STS Policy, making the Policy Domain appear not to have an MTA- 451 STS Policy. The sender policy cache is designed to resist this 452 attack by decreasing the frequency of policy discovery and thus 453 reducing the window of vulnerability; it is nonetheless a risk that 454 attackers who can predict or induce policy discovery--for example, by 455 inducing a victim sending domain to send mail to a never-before- 456 contacted recipient while carrying out a man-in-the-middle attack-- 457 may be able to foil policy discovery and effectively downgrade the 458 security of the message delivery. 460 Since this attack depends upon intercepting initial policy discovery, 461 we strongly recommend implementors to prefer policy "max_age" values 462 to be as long as is practical. 464 Because this attack is also possible upon refresh of a cached policy, 465 we suggest implementors do not wait until a cached policy has expired 466 before checking for an update; if senders attempt to refresh the 467 cache regularly (for instance, by checking their cached version 468 string against the TXT record on each successful send, or in a 469 background task that runs daily or weekly), an attacker would have to 470 foil policy discovery consistently over the lifetime of a cached 471 policy to prevent a successful refresh. 473 Resistence to downgrade attacks of this nature--due to the ability to 474 authoritatively determine "lack of a record" even for non- 475 participating recipients--is a feature of DANE, due to its use of 476 DNSSEC for policy discovery. 478 8.3. Denial of Service 480 We additionally consider the Denial of Service risk posed by an 481 attacker who can modify the DNS records for a victim domain. Absent 482 MTA-STS, such an attacker can cause a sending MTA to cache invalid MX 483 records, but only for however long the sending resolver caches those 484 records. With MTA-STS, the attacker can additionally advertise a 485 new, long-"max_age" MTA-STS policy with "mx" constraints that 486 validate the malicious MX record, causing senders to cache the policy 487 and refuse to deliver messages once the victim has resecured the MX 488 records. 490 This attack is mitigated in part by the ability of a victim domain to 491 (at any time) publish a new policy updating the cached, malicious 492 policy, though this does require the victim domain to both obtain a 493 valid CA-signed certificate and to understand and properly configure 494 MTA-STS. 496 Similarly, we consider the possibility of domains that deliberately 497 allow untrusted users to serve untrusted content on user-specified 498 subdomains. In some cases (e.g. the service Tumblr.com) this takes 499 the form of providing HTTPS hosting of user-registered subdomains; in 500 other cases (e.g. dynamic DNS providers) this takes the form of 501 allowing untrusted users to register custom DNS records at the 502 provider's domain. 504 In these cases, there is a risk that untrusted users would be able to 505 serve custom content at the "mta-sts" host, including serving an 506 illegitimate MTA-STS policy. We believe this attack is rendered more 507 difficult by the need for the attacker to also serve the "_mta-sts" 508 TXT record on the same domain--something not, to our knowledge, 509 widely provided to untrusted users. This attack is additionally 510 mitigated by the aforementioned ability for a victim domain to update 511 an invalid policy at any future date. 513 8.4. Weak Policy Constraints 515 Even if an attacker cannot modify a served policy, the potential 516 exists for configurations that allow attackers on the same domain to 517 receive mail for that domain. For example, an easy configuration 518 option when authoring an MTA-STS Policy for "example.com" is to set 519 the "mx" equal to ".example.com"; recipient domains must consider in 520 this case the risk that any user possessing a valid hostname and CA- 521 signed certificate (for example, "dhcp-123.example.com") will, from 522 the perspective of MTA-STS Policy validation, be a valid MX host for 523 that domain. 525 9. Contributors 527 Nicolas Lidzborski Google, Inc nlidz (at) google (dot com) 529 Wei Chuang Google, Inc weihaw (at) google (dot com) 531 Brandon Long Google, Inc blong (at) google (dot com) 533 Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com) 535 Klaus Umbach 1&1 Mail & Media Development & Technology GmbH 536 klaus.umbach (at) 1und1 (dot de) 538 Markus Laber 1&1 Mail & Media Development & Technology GmbH 539 markus.laber (at) 1und1 (dot de) 541 10. Appendix 1: MTA-STS example record & policy 543 The owner of "example.com" wishes to begin using MTA-STS with a 544 policy that will solicit reports from senders without affecting how 545 the messages are processed, in order to verify the identity of MXs 546 that handle mail for "example.com", confirm that TLS is correctly 547 used, and ensure that certificates presented by the recipient MX 548 validate. 550 MTA-STS policy indicator TXT RR: 552 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 554 MTA-STS Policy JSON served as the response body at [1] 556 { 557 "version": "STSv1", 558 "mode": "report", 559 "mx": ["mx1.example.com", "mx2.example.com"], 560 "max_age": 12345678 561 } 563 11. Appendix 2: Message delivery pseudocode 565 Below is pseudocode demonstrating the logic of a compliant sending 566 MTA. 568 While this pseudocode implementation suggests synchronous policy 569 retrieval in the delivery path, in a working implementation that may 570 be undesirable, and we expect some implementors to instead prefer a 571 background fetch that does not block delivery if no cached policy is 572 present. 574 func isEnforce(policy) { 575 // Return true if the policy mode is "enforce". 576 } 578 func isNonExpired(policy) { 579 // Return true if the policy is not expired. 580 } 582 func tryStartTls(mx) { 583 // Attempt to open an SMTP connection with STARTTLS with the MX. 584 } 586 func certMatches(connection, mx) { 587 // For simplicity, we are not checking CNs here. 588 for san in getSansFromCert(connection) { 589 // Return if the server certificate from "connection" matches the "mx" host. 590 if san[0] == '*' { 591 // Invalid wildcard! 592 if san[1] != '.' return false 593 san = san[1:] 594 } 595 if san[0] == '.' && HasSuffix(mx, san) { 596 return true 597 } 598 if mx[0] == '.' && HasSuffix(san, mx) { 599 return true 600 } 601 if mx == san { 602 return true 603 } 604 } 605 return false 606 } 608 func tryDeliverMail(connection, message) { 609 // Attempt to deliver "message" via "connection". 610 } 612 func tryGetNewPolicy(domain) { 613 // Check for an MTA-STS TXT record for "domain" in DNS, and return the 614 // indicated policy. 616 } 618 func cachePolicy(domain, policy) { 619 // Store "policy" as the cached policy for "domain". 620 } 622 func tryGetCachedPolicy(domain) { 623 // Return a cached policy for "domain". 624 } 626 func reportError(error) { 627 // Report an error via TLSRPT. 628 } 630 func tryMxAccordingTo(message, mx, policy) { 631 connection := connect(mx) 632 if !connection { 633 return false // Can't connect to the MX so it's not an MTA-STS error. 634 } 635 secure := true 636 if !tryStartTls(mx, &connection) { 637 secure = false 638 reportError(E_NO_VALID_TLS) 639 } else if !certMatches(connection, mx) { 640 secure = false 641 reportError(E_CERT_MISMATCH) 642 } 643 if secure || !isEnforce(policy) { 644 return tryDeliverMail(connection, message) 645 } 646 return false 647 } 649 func tryWithPolicy(message, domain, policy) { 650 for mx in mxes { 651 if tryMxAccordingTo(message, mx, policy) { 652 return true 653 } 654 } 655 return false 656 } 658 func handleMessage(message) { 659 domain := ... // domain part after '@' from recipient 660 policy := tryGetNewPolicy(domain) 661 if policy { 662 cachePolicy(domain, policy) 663 } else { 664 policy = tryGetCachedPolicy(domain) 665 } 666 if policy { 667 return tryWithPolicy(message, policy) 668 } 669 // Try to deliver the message normally (i.e. without MTA-STS). 670 } 672 12. References 674 12.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 678 RFC2119, March 1997, 679 . 681 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 682 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 683 February 2002, . 685 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 686 for Internationalized Domain Names in Applications 687 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 688 . 690 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 691 Rose, "DNS Security Introduction and Requirements", RFC 692 4033, DOI 10.17487/RFC4033, March 2005, 693 . 695 [RFC4627] Crockford, D., "The application/json Media Type for 696 JavaScript Object Notation (JSON)", RFC 4627, DOI 10 697 .17487/RFC4627, July 2006, 698 . 700 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 701 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 702 RFC5234, January 2008, 703 . 705 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 706 Housley, R., and W. Polk, "Internet X.509 Public Key 707 Infrastructure Certificate and Certificate Revocation List 708 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 709 . 711 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 712 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10 713 .17487/RFC5785, April 2010, 714 . 716 [RFC5891] Klensin, J., "Internationalized Domain Names in 717 Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ 718 RFC5891, August 2010, 719 . 721 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 722 Verification of Domain-Based Application Service Identity 723 within Internet Public Key Infrastructure Using X.509 724 (PKIX) Certificates in the Context of Transport Layer 725 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 726 2011, . 728 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 729 Opportunistic DNS-Based Authentication of Named Entities 730 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10 731 .17487/RFC7672, October 2015, 732 . 734 12.2. URIs 736 [1] https://mta-sts.example.com/.well-known/mta-sts.json: 738 Authors' Addresses 740 Daniel Margolis 741 Google, Inc 743 Email: dmargolis (at) google.com 745 Mark Risher 746 Google, Inc 748 Email: risher (at) google (dot com) 750 Binu Ramakrishnan 751 Yahoo!, Inc 753 Email: rbinu (at) yahoo-inc (dot com) 754 Alexander Brotman 755 Comcast, Inc 757 Email: alex_brotman (at) comcast.com 759 Janet Jones 760 Microsoft, Inc 762 Email: janet.jones (at) microsoft (dot com)