idnits 2.17.1 draft-margolis-smtp-sts-00.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A sending MTA who does not support the validation method required--for example, an MTA that does not have a DNSSEC-compatible resolver--MUST behave as though the policy did not validate. As described in the section on _Policy_ _Application_, a policy which has not ever been successfully validated MUST not be used to reject mail. -- The document date (March 18, 2016) is 2961 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) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 N. Lidzborski 5 Expires: September 19, 2016 W. Chuang 6 B. Long 7 Google, Inc 8 B. Ramakrishnan 9 Yahoo!, Inc 10 A. Brotman 11 Comcast, Inc 12 J. Jones 13 Microsoft, Inc 14 F. Martin 15 LinkedIn 16 K. Umbach 17 M. Laber 18 1&1 Mail & Media Development & Technology GmbH 19 March 18, 2016 21 SMTP Strict Transport Security 22 draft-margolis-smtp-sts-00 24 Abstract 26 SMTP STS is a mechanism enabling mail service providers to declare 27 their ability to receive TLS-secured connections, to declare 28 particular methods for certificate validation, and to request sending 29 SMTP servers to report upon and/or refuse to deliver messages that 30 cannot be delivered securely. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 19, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Differences from DANE . . . . . . . . . . . . . . . . . . 4 70 2.2. Advantages When Used with DANE . . . . . . . . . . . . . 4 71 2.3. Advantages When Used Without DANE . . . . . . . . . . . . 4 72 2.4. Disadvantages When Used Without DANE . . . . . . . . . . 5 73 3. Policy Semantics . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Policy Expirations . . . . . . . . . . . . . . . . . . . 8 76 3.3. Policy Authentication . . . . . . . . . . . . . . . . . . 8 77 3.4. Policy Validation . . . . . . . . . . . . . . . . . . . . 9 78 3.5. Policy Application . . . . . . . . . . . . . . . . . . . 9 79 4. Failure Reporting . . . . . . . . . . . . . . . . . . . . . . 10 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8. Appendix 1: Validation Pseudocode . . . . . . . . . . . . . . 14 84 9. Appendix 2: Domain Owner STS example record . . . . . . . . . 14 85 10. Appendix 3: XML Schema for Failure Reports . . . . . . . . . 14 86 11. Appendix 4: Example report . . . . . . . . . . . . . . . . . 16 87 12. Normative References . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 93 hosts to establish secure SMTP sessions over TLS. In its current 94 form, however, it fails to provide (a) message confidentiality -- 95 because opportunistic STARTTLS is subject to downgrade attacks -- and 96 (b) server authenticity -- because the trust relationship from email 97 domain to MTA server identity is not cryptographically validated. 99 While such "opportunistic" encryption protocols provide a high 100 barrier against passive man-in-the-middle traffic interception, any 101 attacker who can delete parts of the SMTP session (such as the "250 102 STARTTLS" response) or who can redirect the entire SMTP session 103 (perhaps by overwriting the resolved MX record of the delivery 104 domain) can perform such a downgrade or interception attack. 106 This document defines a mechanism for recipient domains to publish 107 policies specifying: 109 o whether MTAs sending mail to this domain can expect TLS support 111 o how MTAs can validate the TLS server certificate presented during 112 mail delivery 114 o what an implementing sender should do with messages when TLS 115 cannot be be successfully negotiated 117 The mechanism described is separated into four logical components: 119 1. policy semantics: whether senders can expect a server for the 120 recipient domain to support TLS encryption and how to validate 121 the TLS certificate presented 123 2. policy authentication: how to determine the authenticity of a 124 published policy delivered via DNS 126 3. failure report format: a mechanism for informing recipient 127 domains about aggregate failure statistics 129 4. failure handling: what sending MTAs should do in the case of 130 policy failures 132 1.1. Terminology 134 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 135 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 136 document, are to be interpreted as described in [RFC2119]. 138 We also define the following terms for further use in this document: 140 o STS Policy: A definition of the expected TLS availability and 141 behavior, as well as the desired actions for a given domain when a 142 sending MTA encounters different results. 144 o Policy Domain: The domain against which an STS Policy is defined. 146 2. Related Technologies 148 The DANE TLSA record [RFC7672] is similar, in that DANE is also 149 designed to upgrade opportunistic encryption into required 150 encryption. DANE requires DNSSEC [RFC4033] for the secure delivery 151 of policies; the mechanism described here presents a variant for 152 systems not yet supporting DNSSEC, and specifies a method for 153 reporting TLS negotiation failures. 155 2.1. Differences from DANE 157 The primary difference between the mechanism described here and DANE 158 is that DANE requires the use of DNSSEC to authenticate DANE TLSA 159 records, whereas SMTP STS relies on the certificate authority (CA) 160 system and a trust-on-first-use (TOFU) approach to avoid 161 interception. The TOFU model allows a degree of security similar to 162 that of HPKP [RFC7469], reducing the complexity but without the 163 guarantees on first use offered by DNSSEC. (For a thorough 164 discussion of this trade-off, see the section _Security_ 165 _Considerations_.) 167 In addition, SMTP STS introduces a mechanism for failure reporting 168 and a report-only mode, enabling progressive roll-out and auditing 169 for compliance. 171 2.2. Advantages When Used with DANE 173 SMTP STS can be deployed for a recipient domain that also publishes a 174 DANE TLSA record for SMTP. In these cases, the SMTP STS policy can 175 additionally declare a process for failure reporting. 177 2.3. Advantages When Used Without DANE 179 When deployed without a DANE TLSA record, SMTP STS offers the 180 following advantages compared to DANE: 182 o _Infrastructure:_ In comparison to DANE, this proposal does not 183 require DNSSEC be deployed on either the sending or receiving 184 domain. In addition, the reporting feature of SMTP STS can be 185 deployed to perform offline analysis of STARTTLS failures, 186 enabling mail providers to gain insight into the security of their 187 SMTP connections without the need to modify MTA codebases 188 directly. 190 o _Incrementalism:_ DANE does not provide a reporting mechanism and 191 does not have a concept of "report-only" for failures; as a 192 result, a service provider has no choice but to "flip the switch" 193 and affect the entire mail stream at once. 195 2.4. Disadvantages When Used Without DANE 197 When deployed alone (i.e. without a DANE record, and using Web PKI 198 for certificate verification), SMTP STS offers the following 199 disadvantages compared to DANE: 201 o Infrastructure: DANE may be easier for some providers to deploy. 202 In particular, for providers who already support DNSSEC, SMTP STS 203 would additionally require they obtain a CA-signed x509 204 certificate for the recipient domain. 206 o Security: DANE offers an advantage against policy-lookup DoS 207 attacks; that is, while a DNSSEC-signed NX response to a DANE 208 lookup authoritatively indicates the lack of a DANE record, such 209 an option to authenticate policy non-existence does not exist when 210 looking up a policy over plain DNS. 212 3. Policy Semantics 214 SMTP STS policies are distributed at the Policy Domain either through 215 a new resource record, or as TXT records (similar to DMARC policies) 216 under the name "_smtp_sts." (Current implementations deploy as TXT 217 records.) For example, for the Policy Domain "example.com", the 218 recipient's SMTP STS policy can be retrieved from 219 "_smtp_sts.example.com." 221 (Future implementations may move to alternate methods of policy 222 discovery or distribution. See the section _Future_ _Work_ for more 223 discussion.) 225 Policies MUST specify the following fields: 227 o v: Version (plain-text, required). Currently only "STS1" is 228 supported. 230 o to: TLS-Only (plain-text, required). If "true," the receiving MTA 231 requests that messages be delivered only if they conform to the 232 STS policy. If "false," the receiving MTA requests that failure 233 reports be delivered, as specified by the "rua" parameter. 235 o mx: MX patterns (comma-separated list of plain-text MX match 236 patterns, required). One or more comma-separated patterns 237 matching the expected MX for this domain. For example, 238 "_.example.com,_.example.net" indicates that mail for this domain 239 might be handled by any MX whose hostname is a subdomain of 240 "example.com" or "example.net." 242 o a: The mechanism to use to authenticate this policy itself. See 243 the section _Policy_ _Authentication_ for more details. Possible 244 values are: 246 * webpki:URI, where URI points to an HTTPS resource at the 247 recipient domain that serves the same policy text. 249 * dnssec: Indicating that the policy is expected to be served 250 over DNSSEC. 252 o c: Constraints on the recipient MX's TLS certificate (plain-text, 253 required). See the section _Policy_ _Validation_ for more 254 details. Possible values are: 256 * webpki: Indicating that the TLS certificate presented by the 257 recipient MX will be validated according to the "web PKI" 258 mechanism. 260 * tlsa: Indicating that the TLS certificate presented by the 261 recipient MX will match a (presumed to exist) DANE TLSA record. 263 o e: Max lifetime of the policy (plain-text integer seconds). Well- 264 behaved clients SHOULD cache a policy for up to this value from 265 last policy fetch time. 267 o rua: Address to which aggregate feedback MAY be sent (comma- 268 separated plain-text list of email addresses, optional). For 269 example, "mailto:postmaster@example.com" from [RFC3986]. 271 3.1. Formal Definition 273 The formal definition of the SMTP STS format, using [RFC5234], is as 274 follows: 276 sts-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] 277 ; "URI" is imported from [RFC3986]; commas (ASCII 278 ; 0x2C) and exclamation points (ASCII 0x21) 279 ; MUST be encoded; the numeric portion MUST fit 280 ; within an unsigned 64-bit integer 282 sts-record = sts-version sts-sep sts-to 283 [sts-sep sts-mx] 284 [sts-sep sts-a] 285 [sts-sep sts-c] 286 [sts-sep sts-e] 287 [sts-sep sts-auri] 288 [sts-sep] 289 ; components other than sts-version and 290 ; sts-to may appear in any order 292 sts-version = "v" *WSP "=" *WSP %x53 %x54 %x53 %x31 294 sts-sep = *WSP %x3b *WSP 296 sts-to = "to" *WSP "=" *WSP ( "true" / "false" ) 298 sts-mx = "mx" *WSP "=" *WSP sts-domain-list 300 sts-domain-list = (domain-match *("," domain-match)) 302 domain-match = ["*."] 1*dtext *("." 1*dtext) 304 dtext = %d30-39 / ; 0-9 305 %d41-5A / ; a-z 306 %61-7A / ; A-Z 307 %2D ; "-" 309 sts-a = "a" *WSP "=" *WSP ( URI / "dnssec") 311 sts-c = "c" *WSP "=" *WSP ( "webpki" / "tlsa") 313 sts-e = "e" *WSP "=" *WSP 1*6DIGIT 315 sts-auri = "rua" *WSP "=" *WSP 316 sts-uri *(*WSP "," *WSP sts-uri) 318 A size limitation in a sts-uri, if provided, is interpreted as a 319 count of units followed by an OPTIONAL unit size ("k" for kilobytes, 320 "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a 321 unit, the number is presumed to be a basic byte count. Note that the 322 units are considered to be powers of two; a kilobyte is 2^10, a 323 megabyte is 2^20, etc. 325 3.2. Policy Expirations 327 In order to resist attackers inserting a fraudulent policy, SMTP STS 328 policies are designed to be long-lived, with an expiry typically 329 greater than two weeks. Policy validity is controlled by two 330 separate expiration times: the lifetime indicated in the policy 331 ("e=") and the TTL on the DNS record itself. The policy expiration 332 will ordinarily be longer than that of the DNS TTL, and senders 333 SHOULD cache a policy (and apply it to all mail to the recipient 334 domain) until the policy expiration. 336 An important consideration for domains publishing a policy is that 337 senders will see a policy expiration as relative to the fetch of a 338 policy cached by their recursive resolver. Consequently, a sender 339 MAY treat a policy as valid for up to {expiration time} + {DNS TTL}. 340 Publishers SHOULD thus continue to expect senders to apply old 341 policies for up to this duration. 343 3.3. Policy Authentication 345 The security of a domain implementing an SMTP STS policy against an 346 active man-in-the-middle depends primarily upon the long-lived 347 caching of policies. However, to allow recipient domains to safely 348 serve new policies _prior_ to the expiration of a cached policy, and 349 to prevent long-term (either malicious or active) denials of service, 350 it is important that senders are able to validate a new policy 351 retrieved for a recipient domain. There are two supported mechanisms 352 for policy validation: 354 o Web PKI: In this mechanism, indicated by the "webpki" value of the 355 "a" field, the sender fetches a HTTPS resource from the URI 356 indicated. For example, a=webpki: indicates that the sender should fetch the 358 resource . In 359 order for the policy to be valid, the HTTP response body served at 360 this resource MUST exactly match the policy initially loaded via 361 the DNS TXT method, and MUST be served from an HTTPS endpoint at 362 the domain matching that of the recipient domain. (As this RFC 363 progress, the authors intend to register .well-known/smtp-sts. 364 See [RFC5785]. See _Future_ _Work_ for more information.) 366 o DNSSEC: In this mechanism, indicated by the "dnssec" value of the 367 "a" field, the sender MUST retrieve the policy via a DNSSEC signed 368 response for the _smtp_sts TXT record. 370 When fetching a new policy when one is not already known, or when 371 fetching a policy for a domain with an expired policy, 372 unauthenticated policies MUST be trusted and honored. When fetching 373 a policy and authenticating it, as described in detail in _Policy_ 374 _Application_, policies will be authenticated using the mechanism 375 specified by the existing cached policy. 377 Note, however, as described in detail in _Policy_ _Application_, that 378 new policies MUST NOT be considered as valid if they do not validate 379 on first application. That is, a freshly fetched (and unused) policy 380 that has not successfully been applied MUST be disregarded. 382 3.4. Policy Validation 384 When sending to an MX at a domain for which the sender has a valid 385 and non-expired SMTP STS policy, a sending MTA honoring SMTP STS 386 SHOULD validate that the recipient MX supports STARTTLS and offers a 387 TLS certificate which is valid according to the semantics of the SMTP 388 STS policy. Policies can specify certificate validity in one of two 389 ways by setting the value of the "c" field in the policy description. 391 o Web PKI: When the "c" field is set to "webpki", the certificate 392 presented by the receiving MX MUST be valid for the MX name and 393 chain to a root CA that is trusted by the sending MTA. The 394 certificate MUST have a CN or SAN matching the MX hostname (as 395 described in [RFC6125]) and be non-expired. 397 o DANE TLSA: When the "c" field is set to "tlsa", the receiving MX 398 MUST be covered by a DANE TLSA record for the recipient domain, 399 and the presented certificate MUST be valid according to that 400 record (as described by [RFC7672]). 402 A sending MTA who does not support the validation method required-- 403 for example, an MTA that does not have a DNSSEC-compatible resolver-- 404 MUST behave as though the policy did not validate. As described in 405 the section on _Policy_ _Application_, a policy which has not ever 406 been successfully validated MUST not be used to reject mail. 408 3.5. Policy Application 410 When sending to an MX at a domain for which the sender has a valid 411 non-expired SMTP STS policy, a sending MTA honoring SMTP STS MAY 412 apply the result of a policy validation one of two ways: 414 o Report-only: In this mode, sending MTAs merely send a report to 415 the designated report address indicating policy application 416 failures. This can be done "offline", i.e. based on the MTA logs, 417 and is thus a suitable low-risk option for MTAs who wish to 418 enhance transparency of TLS tampering without making complicated 419 changes to production mail-handling infrastructure. 421 o Enforced: In this mode, sending MTAs SHOULD treat STS policy 422 failures, in which the policy action is "reject", as a mail 423 delivery error, and SHOULD terminate the SMTP connection, not 424 delivering any more mail to the recipient MTA. 426 In enforced mode, however, sending MTAs MUST first check for a new 427 _authenticated_ policy before actually treating a message failure as 428 fatal. 430 Thus the control flow for a sending MTA that does online policy 431 application consists of the following steps: 433 1. Check for cached non-expired policy. If none exists, fetch the 434 latest and cache it. 436 2. Validate recipient MTA against policy. If valid, deliver mail. 438 3. If policy invalid and policy specifies reporting, generate 439 report. 441 4. If policy invalid and policy specifies rejection, perform the 442 following steps: 444 * Check for a new (non-cached) _authenticated_ policy. If one 445 exists, update the current policy and go to step 1. 447 * If none exists or the newly fetched policy also fails, treat 448 the delivery as a failure. 450 Understanding the details of step 4 is critical to understanding the 451 behavior of the system as a whole. 453 Remember that each policy has an expiration time (which SHOULD be 454 long, on the order of days or months) and a validation method. With 455 these two mechanisms and the procedure specified in step 4, 456 recipients who publish a policy have, in effect, a means of updating 457 a cached policy at arbitrary intervals, without the risks (of a man- 458 in-the-middle attack) they would incur if they were to shorten the 459 policy expiration time. 461 4. Failure Reporting 463 Aggregate statistics on policy failures MAY be reported to the URI 464 indicated in the "rua" field of the policy. SMTP STS reports contain 465 information about policy failures to allow diagnosis of 466 misconfigurations and malicious activity. 468 (There may also be a need for enabling more detailed "forensic" 469 reporting during initial stages of a deployment. To address this, 470 the authors consider the possibility of an optional additional 471 "forensic reporting mode" in which more details--such as certificate 472 chains and MTA banners--may be reported. See the section _Future_ 473 _Work_ for more details.) 475 Aggregate reports contain the following fields: 477 o The SMTP STS policy applied (as a string) 479 o The beginning and end of the reporting period 481 Repeated records contain the following fields: 483 o Failure type: This list will start with the minimal set below, and 484 is expected to grow over time based on real-world experience. The 485 initial set is: 487 * mx-mismatch: This indicates that the MX resolved for the 488 recipient domain did not match the MX constraint specified in 489 the policy. 491 * certificate-mismatch: This indicates that the certificate 492 presented by the receiving MX did not match the MX hostname 494 * invalid-certificate: This indicates that the certificate 495 presented by the receiving MX did not validate according to the 496 policy validation constraint. (Either it was not signed by a 497 trusted CA or did not match the DANE TLSA record for the 498 recipient MX.) 500 * expired-certificate: This indicates that the certificate has 501 expired. 503 * starttls-not-supported: This indicates that the recipient MX 504 did not support STARTTLS. 506 * tlsa-invalid: This indicates a validation error for Policy 507 Domain specifying "tlsa" validation. 509 * dnssec-invalid: This indicates a failure to validate DNS 510 records for a Policy Domain specifying "tlsa" validation or 511 "dnssec" authentication. 513 * sender-does-not-support-validation-method: This indicates the 514 sending system can never validate using the requested 515 validation mechanism. 517 o Count: The number of times the error was encountered. 519 o Hostname: The hostname of the recipient MX. 521 Note that the failure types are non-exclusive; an aggregate report 522 MAY contain overlapping counts of failure types where a single send 523 attempt encountered multiple errors. 525 When sending failure reports, sending MTAs MUST NOT honor SMTP STS or 526 DANE TLSA failures. 528 5. IANA Considerations 530 The ".well-known" URI for Policy Domains to host their STS Policies 531 will be registered by following the procedure documented in [RFC5785] 532 (i.e. sending a request to the "wellknown-uri-review@ietf.org" 533 mailing list for review and comment). The proposed URI-suffix is 534 "smtp-sts". 536 6. Security Considerations 538 SMTP Strict Transport Security protects against an active attacker 539 who wishes to intercept or tamper with mail between hosts who support 540 STARTTLS. There are two classes of attacks considered: 542 o Foiling TLS negotiation, for example by deleting the "250 543 STARTTLS" response from a server or altering TLS session 544 negotiation. This would result in the SMTP session occurring over 545 plaintext, despite both parties supporting TLS. 547 o Impersonating the destination mail server, whereby the sender 548 might deliver the message to an impostor, who could then monitor 549 and/or modify messages despite opportunistic TLS. This 550 impersonation could be accomplished by spoofing the DNS MX record 551 for the recipient domain, or by redirecting client connections to 552 the legitimate recipient server (for example, by altering BGP 553 routing tables). 555 SMTP Strict Transport Security relies on certificate validation via 556 either TLS identity checking [RFC6125] or DANE TLSA [RFC7672]. 557 Attackers who are able to obtain a valid certificate for the targeted 558 recipient mail service (e.g. by compromising a certificate authority) 559 are thus out of scope of this threat model. 561 In the WebPKI constraint mode, an attacker who is able to block DNS 562 responses can suppress the delivery of an STS Policy, making the 563 Policy Domain appear not to have an STS Policy. The caching model 564 described in _Policy_ _Expirations_ is designed to resist this 565 attack, and there is discussion in the _Future_ _Work_ section around 566 future distribution mechanisms that are robust against this attack. 568 7. Future Work 570 The authors would like to suggest multiple considerations for future 571 discussion. 573 o Certificate pinning: One potential improvement in the robustness 574 of the certificate validation methods discussed would be the 575 deployment of public-key pinning as defined for HTTP in [RFC7469]. 576 A policy extension supporting these semantics would enable Policy 577 Domains to specify certificates that MUST appear in the MX 578 certificate chain, thus providing resistence against compromised 579 CA or DNSSEC zone keys. 581 o Policy distribution: As with Certificate Transparency ([RFC6962]), 582 it may be possible to provide a verifiable log of policy 583 _observations_ (meaning which policies have been observed for a 584 given Policy Domain). This would provide insight into policy 585 spoofing or faked policy non-existence. This may be particularly 586 useful for Policy Domains not using DNSSEC, since it would provide 587 sending MTAs an authoritative source for whether a policy is 588 expected for a given domain. 590 o Receive-from restrictions: Policy publishers may wish to also 591 indicate to domains _receiving_ mail from the Policy Domain that 592 all such mail is expected to be sent via TLS. This may allow 593 policy publishers to receive reports indicating sending MTA 594 misconfigurations. However, the security properties of a 595 "receiver-enforced" system differ from those of the current 596 design; in particular, an active man-in-the-middle attacker may be 597 able to exploit misconfigured sending MTAs in a way that would not 598 be possible today with a sender-enforced model. 600 o Cipher and TLS version restrictions: Policy publishers may also 601 wish to restrict TLS negotiation to specific ciphers or TLS 602 versions. 604 In addition, the authors leave currently open the following details: 606 o Whether and how more detailed "forensic reporting" should be 607 accomplished, as discussed in the section _Failure_ _Reporting_. 609 o The registration of the .well-known/smtp-sts URI as per [RFC5785]. 611 8. Appendix 1: Validation Pseudocode 613 policy = policy_from_cache() 614 if not policy or is_expired(policy): 615 policy = policy_from_dns() // fetch and authenticate! 616 update_cache = true 617 if policy: 618 if invalid_mx_or_tls(policy): // check MX and TLS cert 619 if rua: 620 generate_report() 621 if p_reject(): 622 policy = policy_from_dns() // fetch and authenticate #2! 623 update_cache = true 624 if invalid_mx_or_tls(policy): 625 reject_message() 626 update_cache = false 627 if update_cache: 628 cache(policy) 630 9. Appendix 2: Domain Owner STS example record 632 The owner wishes to begin using STS 633 with a policy that will solicit aggregate feedback from receivers 634 without affecting how the messages are processed, in order to: 636 * Confirm that its legitimate messages are sent over TLS 638 * Verify the validity of the certificates 640 * Verify what cyphers are in use 642 * Determine how many messages would be affected by a strict policy 644 _smtp_sts IN TXT ( "v=STS1; to=false; " 645 "rua=mailto:sts-feedback@example.com " ) 647 10. Appendix 3: XML Schema for Failure Reports 649 650 653 655 656 657 658 659 660 662 663 664 665 666 667 669 670 671 672 674 675 676 677 678 679 680 682 683 684 685 686 688 689 690 692 693 694 695 696 697 698 699 700 701 702 703 704 706 707 708 709 710 711 713 714 715 716 717 718 719 720 721 722 724 725 726 727 728 730 732 734 736 738 739 740 741 743 11. Appendix 4: Example report 744 745 1 746 747 Company XYZ 748 sts-reporting@company.com 749 750 12345 751 1439227624 752 1439313998 753 754 755 company.com 756 *.mx.mail.company.com 757 WebPKI 758 759 ReportOnly 760 761 ExpiredCertificate 762 13128 763 mta7.am0.yahoodns.net. 764 98.136.216.25 765 766 767 StarttlsNotSupported 768 19 769 mta7.am0.yahoodns.net. 770 98.22.33.99 771 772 774 12. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 782 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 783 February 2002, . 785 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 786 Resource Identifier (URI): Generic Syntax", STD 66, 787 RFC 3986, DOI 10.17487/RFC3986, January 2005, 788 . 790 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 791 Rose, "DNS Security Introduction and Requirements", 792 RFC 4033, DOI 10.17487/RFC4033, March 2005, 793 . 795 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 796 Specifications: ABNF", STD 68, RFC 5234, 797 DOI 10.17487/RFC5234, January 2008, 798 . 800 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 801 Uniform Resource Identifiers (URIs)", RFC 5785, 802 DOI 10.17487/RFC5785, April 2010, 803 . 805 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 806 Verification of Domain-Based Application Service Identity 807 within Internet Public Key Infrastructure Using X.509 808 (PKIX) Certificates in the Context of Transport Layer 809 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 810 2011, . 812 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 813 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 814 . 816 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 817 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 818 2015, . 820 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 821 Opportunistic DNS-Based Authentication of Named Entities 822 (DANE) Transport Layer Security (TLS)", RFC 7672, 823 DOI 10.17487/RFC7672, October 2015, 824 . 826 Authors' Addresses 828 Daniel Margolis 829 Google, Inc 831 Email: dmargolis (at) google.com 833 Mark Risher 834 Google, Inc 836 Email: risher (at) google (dot com) 837 Nicolas Lidzborski 838 Google, Inc 840 Email: nlidz (at) google (dot com) 842 Wei Chuang 843 Google, Inc 845 Email: weihaw (at) google (dot com) 847 Brandon Long 848 Google, Inc 850 Email: blong (at) google (dot com) 852 Binu Ramakrishnan 853 Yahoo!, Inc 855 Email: rbinu (at) yahoo-inc (dot com) 857 Alexander Brotman 858 Comcast, Inc 860 Email: alexander_brotman (at) cable.comcast (dot com) 862 Janet Jones 863 Microsoft, Inc 865 Email: janet.jones (at) microsoft (dot com) 867 Franck Martin 868 LinkedIn 870 Email: fmartin (at) linkedin (dot com) 872 Klaus Umbach 873 1&1 Mail & Media Development & Technology GmbH 875 Email: klaus.umbach (at) 1und1 (dot de) 876 Markus Laber 877 1&1 Mail & Media Development & Technology GmbH 879 Email: markus.laber (at) 1und1 (dot de)