idnits 2.17.1 draft-ietf-uta-mta-sts-01.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 17 instances of too long lines in the document, the longest one being 6 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 (July 8, 2016) is 2849 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 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) Summary: 4 errors (**), 0 flaws (~~), 2 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: January 9, 2017 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 July 8, 2016 21 SMTP MTA Strict Transport Security 22 draft-ietf-uta-mta-sts-01 24 Abstract 26 SMTP MTA-STS is a mechanism enabling mail service providers to 27 declare their ability to receive TLS-secured connections, to declare 28 particular methods for certificate validation, and to request that 29 sending SMTP servers report upon and/or refuse to deliver messages 30 that 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 January 9, 2017. 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.1.1. Advantages of SMTP MTA-STS when compared to DANE . . 4 71 2.1.2. Advantages of DANE when compared to SMTP MTA-STS . . 5 72 3. Policy Semantics . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 74 3.1.1. TXT Record . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.2. SMTP MTA-STS Policy . . . . . . . . . . . . . . . . . 6 76 3.2. Policy Expirations . . . . . . . . . . . . . . . . . . . 7 77 3.2.1. Policy Updates . . . . . . . . . . . . . . . . . . . 8 78 3.3. Policy Discovery & Authentication . . . . . . . . . . . . 8 79 3.4. Policy Validation . . . . . . . . . . . . . . . . . . . . 9 80 3.5. Policy Application . . . . . . . . . . . . . . . . . . . 9 81 4. Failure Reporting . . . . . . . . . . . . . . . . . . . . . . 10 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8. Appendix 1: Validation Pseudocode . . . . . . . . . . . . . . 12 86 9. Appendix 2: Domain Owner STS example record . . . . . . . . . 12 87 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 88 10. Appendix 3: DEEP Registration Elements . . . . . . . . . . . 13 89 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 95 hosts to establish secure SMTP sessions over TLS. In its current 96 form, however, it fails to provide (a) message confidentiality -- 97 because opportunistic STARTTLS is subject to downgrade attacks -- and 98 (b) server authenticity -- because the trust relationship from email 99 domain to MTA server identity is not cryptographically validated. 101 While such _opportunistic_ encryption protocols provide a high 102 barrier against passive man-in-the-middle traffic interception, any 103 attacker who can delete parts of the SMTP session (such as the "250 104 STARTTLS" response) or who can redirect the entire SMTP session 105 (perhaps by overwriting the resolved MX record of the delivery 106 domain) can perform such a downgrade or interception attack. 108 This document defines a mechanism for recipient domains to publish 109 policies specifying: 111 o whether MTAs sending mail to this domain can expect TLS support 113 o how MTAs can validate the TLS server certificate presented during 114 mail delivery 116 o the expected identity of MXs that handle mail for this domain 118 o what an implementing sender should do with messages when TLS 119 cannot be successfully negotiated 121 The mechanism described is separated into four logical components: 123 1. policy semantics: whether senders can expect a server for the 124 recipient domain to support TLS encryption and how to validate 125 the TLS certificate presented 127 2. policy discovery & authentication: how to discover a domain's 128 published STS policy and determine the authenticity of that 129 policy 131 3. failure report format: a mechanism for informing recipient 132 domains about aggregate failure statistics 134 4. failure handling: what sending MTAs should do in the case of 135 policy failures 137 1.1. Terminology 139 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 140 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 141 document, are to be interpreted as described in [RFC2119]. 143 We also define the following terms for further use in this document: 145 o STS Policy: A definition of the expected TLS availability and 146 behavior, as well as the desired actions for a given domain when a 147 sending MTA encounters different results. 149 o Policy Domain: The domain against which an STS Policy is defined. 151 o Policy Authentication: Authentication of the STS policy retrieved 152 for a recipient domain by the sender. 154 2. Related Technologies 156 The DANE TLSA record [RFC7672] is similar, in that DANE is also 157 designed to upgrade opportunistic encryption into required 158 encryption. DANE requires DNSSEC [RFC4033] for the secure delivery 159 of policies; the mechanism described here presents a variant for 160 systems not yet supporting DNSSEC. 162 2.1. Differences from DANE 164 The primary difference between the mechanism described here and DANE 165 is that DANE requires the use of DNSSEC to authenticate DANE TLSA 166 records, whereas SMTP STS relies on the certificate authority (CA) 167 system to avoid interception. (For a thorough discussion of this 168 trade-off, see the section _Security_ _Considerations_.) 170 In addition, SMTP MTA-STS introduces a mechanism for failure 171 reporting and a report-only mode, enabling offline ("report-only") 172 deployments and auditing for compliance. 174 2.1.1. Advantages of SMTP MTA-STS when compared to DANE 176 SMTP MTA-STS offers the following advantages compared to DANE: 178 o Infrastructure: In comparison to DANE, this proposal does not 179 require DNSSEC be deployed on either the sending or receiving 180 domain. In addition, the reporting feature of SMTP MTA-STS can be 181 deployed to perform offline analysis of STARTTLS failures, 182 enabling mail providers to gain insight into the security of their 183 SMTP connections without the need to modify MTA codebases 184 directly. 186 o Offline or report-only usage: DANE does not provide a reporting 187 mechanism and does not have a concept of "report-only" for 188 failures; as a result, a service provider cannot receive metrics 189 on TLS acceptability without asking senders to enforce a given 190 policy; similarly, senders who cannot enforce DANE constraints at 191 send-time have no mechanism to provide recipients such metrics 192 from an offline (and potentially easier-to-deploy) logs-analysis 193 batch process. 195 2.1.2. Advantages of DANE when compared to SMTP MTA-STS 197 o Infrastructure: DANE may be easier for some providers to deploy. 198 In particular, for providers who already support DNSSEC, SMTP MTA- 199 STS would additionally require they host a HTTPS webserver and 200 obtain a CA-signed X.509 certificate for the recipient domain. 202 o Security: DANE offers an advantage against policy-lookup DoS 203 attacks; that is, while a DNSSEC-signed NXDOMAIN response to a 204 DANE lookup authoritatively indicates the lack of a DANE record, 205 such an option to authenticate policy non-existence does not exist 206 when looking up a policy over plain DNS. 208 3. Policy Semantics 210 SMTP MTA-STS policies are distributed via a "well known" HTTPS 211 endpoint in the Policy Domain. A corresponding TXT record in the DNS 212 alerts sending MTAs to the presence of a policy file. 214 (Future implementations may move to alternate methods of policy 215 discovery or distribution. See the section _Future_ _Work_ for more 216 discussion.) 218 *The MTA-STS TXT record MUST specify the following fields:* 220 o "v": (plain-text, required). Currently only "STSv1" is supported. 222 o "id": (plain-text, required). A short string used to track policy 223 updates. This string MUST uniquely identify a given instance of a 224 policy, such that senders can determine when the policy has been 225 updated by comparing to the "id" of a previously seen policy, and 226 must also match the "policy_id" value of the distributed policy. 228 A lenient parser SHOULD accept a policy file implementing a superset 229 of this specification, in which case unknown values SHALL be ignored. 231 *Policies MUST specify the following fields in JSON* [RFC4627] 232 *format:* 234 o "version": (plain-text, required). Currently only "STSv1" is 235 supported. 237 o "mode": (plain-text, required). If "enforce", the receiving MTA 238 requests that messages be delivered only if they conform to the 239 STS policy. If "report" the receiving MTA requests that failure 240 reports be delivered, as specified by the "rua" parameter. 242 o "mx": MX patterns (list of plain-text MX match patterns, 243 required). One or more comma-separated patterns matching the 244 expected MX for this domain. For example, "["*.example.com", 245 "*.example.net"]" indicates that mail for this domain might be 246 handled by any MX whose hostname is a subdomain of "example.com" 247 or "example.net". The semantics for these patterns should be the 248 ones found in the "Checking of Wildcard Certificates" rules in 249 Section 6.4.3 of [RFC6125]. 251 o "max_age": Max lifetime of the policy (plain-text integer 252 seconds). Well-behaved clients SHOULD cache a policy for up to 253 this value from last policy fetch time. 255 o "policy_id": A short string used to track policy updates. This 256 string MUST uniquely identify a given instance of a policy, such 257 that senders can determine when the policy has been updated by 258 comparing to the "policy_id" of a previously seen policy. 260 A lenient parser SHOULD accept a policy file which is valid JSON 261 implementing a superset of this specification, in which case unknown 262 values SHALL be ignored. 264 3.1. Formal Definition 266 3.1.1. TXT Record 268 The formal definition of the "_mta_sts" TXT record, defined using 269 [RFC5234], is as follows: 271 sts-text-record = sts-version *WSP %x3B *WSP sts-id 273 sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" 274 %x53 %x76 %x31 276 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) 278 3.1.2. SMTP MTA-STS Policy 280 The formal definition of the SMTP MTA-STS policy, using [RFC5234], is 281 as follows: 283 sts-record = WSP %x7B WSP ; { left curly bracket 284 sts-element ; comma-separated 285 [ ; list 286 WSP %x2c WSP ; of 287 sts-element ; sts-elements 288 ] 289 WSP %x7d WSP ; } right curly bracket 291 sts-element = sts-version / sts-mode / sts-id / sts-mx / sts-max_age 293 sts-version = %x22 "version" %x22 *WSP %x3a *WSP ; "version": 294 %x22 %x53 %x54 %x53 %x76 %x31 ; "STSv1" 296 sts-mode = %x22 "mode" %x22 *WSP %x3a *WSP ; "mode": 297 %x22 ("report" / "enforce") %x22 ; "report"/"enforce" 299 sts-id = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id": 300 %x22 1*32(ALPHA / DIGIT) %x22 ; some chars 302 sts-mx = %x22 "mx" $x22 *WSP %x3a *WSP ; "mx": 303 %x5B ; [ 304 domain-match ; comma-separated list 305 [WSP %x2c domain-match WSP] ; of domain-matches 306 %x5B ; ] 308 sts-max_age = %x22 "max_age" %x22 *WSP $x3a *WSP ; "max_age": 309 1*10DIGIT ; some digits 311 domain-match = %x22 1*(dtext / "*") *("." ; wildcard or label 312 1*dtext) %x22 ; with 0+ more labels 314 dtext = ALPHA / DIGIT / %2D ; A-Z, a-z, 0-9, "-" 316 A size limitation in a sts-uri, if provided, is interpreted as a 317 count of units followed by an OPTIONAL unit size ("k" for kilobytes, 318 "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a 319 unit, the number is presumed to be a basic byte count. Note that the 320 units are considered to be powers of two; a kilobyte is 2^10, a 321 megabyte is 2^20, etc. 323 3.2. Policy Expirations 325 In order to resist attackers inserting a fraudulent policy, SMTP MTA- 326 STS policies are designed to be long-lived, with an expiry typically 327 greater than two weeks. Policy validity is controlled by two 328 separate expiration times: the lifetime indicated in the policy 329 ("max_age=") and the TTL on the DNS record itself. The policy 330 expiration will ordinarily be longer than that of the DNS TTL, and 331 senders SHOULD cache a policy (and apply it to all mail to the 332 recipient domain) until the policy expiration. 334 An important consideration for domains publishing a policy is that 335 senders will see a policy expiration as relative to the fetch of a 336 policy cached by their recursive resolver. Consequently, a sender 337 MAY treat a policy as valid for up to {expiration time} + {DNS TTL}. 338 Publishers SHOULD thus continue to expect senders to apply old 339 policies for up to this duration. 341 3.2.1. Policy Updates 343 Updating the policy requires that the owner make changes in two 344 places: the "_mta_sts" RR record in the Policy Domain's DNS zone and 345 at the corresponding HTTPS endpoint. In the case where the HTTPS 346 endpoint has been updated but the TXT record has not been, senders 347 will not know there is a new policy released and may thus continue to 348 use old, previously cached versions. Recipients should thus expect a 349 policy will continue to be used by senders until both the HTTPS and 350 TXT endpoints are updated and the TXT record's TTL has passed. 352 3.3. Policy Discovery & Authentication 354 Senders discover a recipient domain's STS policy, by making an 355 attempt to fetch TXT records from the recipient domain's DNS zone 356 with the name "_mta_sts". A valid TXT record presence in 357 "_mta_sts.example.com" indicates that the recipent domain supports 358 STS. To allow recipient domains to safely serve new policies, it is 359 important that senders are able to authenticate a new policy 360 retrieved for a recipient domain. 362 Web PKI is the mechanism used for policy authentication. In this 363 mechanism, the sender fetches a HTTPS resource (policy) from a host 364 at "policy.mta-sts" in the Policy Domain. The policy is served from 365 a "well known" URI: "https://policy.mta-sts.example.com/.well-known/ 366 mta-sts/current". To consider the policy as valid, the "policy_id" 367 field in the policy MUST match the "id" field in the DNS TXT record 368 under "_mta_sts". 370 When fetching a new policy or updating a policy, the new policy MUST 371 be fully authenticated (HTTPS certificate validation + peer 372 verification) before use. A policy which has not ever been 373 successfully authenticated MUST NOT be used to reject mail. 375 3.4. Policy Validation 377 When sending to an MX at a domain for which the sender has a valid 378 and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA- 379 STS MUST validate that the recipient MX supports STARTTLS, and offers 380 a valid PKIX based TLS certificate. The certificate presented by the 381 receiving MX MUST be valid for the MX name and chain to a root CA 382 that is trusted by the sending MTA. The certificate MUST have a CN 383 or SAN matching the MX hostname (as described in [RFC6125]) and be 384 non-expired. 386 3.5. Policy Application 388 When sending to an MX at a domain for which the sender has a valid 389 non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS 390 MAY apply the result of a policy validation one of two ways: 392 o "report": In this mode, sending MTAs merely send a report to the 393 designated report address indicating policy application failures. 394 This can be done "offline", i.e. based on the MTA logs, and is 395 thus a suitable low-risk option for MTAs who wish to enhance 396 transparency of TLS tampering without making complicated changes 397 to production mail-handling infrastructure. 399 o "enforce": In this mode, sending MTAs SHOULD treat STS policy 400 failures, in which the policy action is "reject", as a mail 401 delivery error, and SHOULD terminate the SMTP connection, not 402 delivering any more mail to the recipient MTA. 404 In "enforce" mode, however, sending MTAs MUST first check for a new 405 authenticated policy before actually treating a message failure as 406 fatal. 408 Thus the control flow for a sending MTA that does online policy 409 application consists of the following steps: 411 1. Check for cached non-expired policy. If none exists, fetch the 412 latest, authenticate and cache it. 414 2. Validate recipient MTA against policy. If valid, deliver mail. 416 3. If not valid and the policy specifies reporting, generate report. 418 4. If not valid and policy specifies rejection, perform the 419 following steps: 421 * Check for a new (non-cached) authenticated policy. 423 * If one exists and the new policy is different, update the 424 current policy and go to step 2. 426 * If one exists and the new policy is same as the cached policy, 427 treat the delivery as a failure. 429 * If none exists and cached policy is not expired, treat the 430 delivery as a failure. 432 Understanding the details of step 4 is critical to understanding the 433 behavior of the system as a whole. 435 Remember that each policy has an expiration time (which SHOULD be 436 long, on the order of days or months) and a validation method. With 437 these two mechanisms and the procedure specified in step 4, 438 recipients who publish a policy have, in effect, a means of updating 439 a cached policy at arbitrary intervals, without the risks (of a man- 440 in-the-middle attack) they would incur if they were to shorten the 441 policy expiration time. 443 4. Failure Reporting 445 Aggregate statistics on policy failures MAY be reported using the 446 "TLSRPT" reporting specification (TODO: Add Ref). 448 5. IANA Considerations 450 There are no IANA considerations at this time. 452 6. Security Considerations 454 SMTP Strict Transport Security protects against an active attacker 455 who wishes to intercept or tamper with mail between hosts who support 456 STARTTLS. There are two classes of attacks considered: 458 o Foiling TLS negotiation, for example by deleting the "250 459 STARTTLS" response from a server or altering TLS session 460 negotiation. This would result in the SMTP session occurring over 461 plaintext, despite both parties supporting TLS. 463 o Impersonating the destination mail server, whereby the sender 464 might deliver the message to an impostor, who could then monitor 465 and/or modify messages despite opportunistic TLS. This 466 impersonation could be accomplished by spoofing the DNS MX record 467 for the recipient domain, or by redirecting client connections 468 intended for the legitimate recipient server (for example, by 469 altering BGP routing tables). 471 SMTP Strict Transport Security relies on certificate validation via 472 PKIX based TLS identity checking [RFC6125]. Attackers who are able 473 to obtain a valid certificate for the targeted recipient mail service 474 (e.g. by compromising a certificate authority) are thus out of scope 475 of this threat model. 477 Since we use DNS TXT record for policy discovery, an attacker who is 478 able to block DNS responses can suppress the discovery of an STS 479 Policy, making the Policy Domain appear not to have an STS Policy. 480 The caching model described in _Policy_ _Expirations_ is designed to 481 resist this attack, and there is discussion in the _Future_ _Work_ 482 section around future distribution mechanisms that are robust against 483 this attack. 485 7. Future Work 487 The authors would like to suggest multiple considerations for future 488 discussion. 490 o Certificate pinning: One potential improvement in the robustness 491 of the certificate validation methods discussed would be the 492 deployment of public-key pinning as defined for HTTP in [RFC7469]. 493 A policy extension supporting these semantics would enable Policy 494 Domains to specify certificates that MUST appear in the MX 495 certificate chain, thus providing resistence against compromised 496 CA or DNSSEC zone keys. 498 o Policy distribution: As with Certificate Transparency ([RFC6962]), 499 it may be possible to provide a verifiable log of policy 500 _observations_ (meaning which policies have been observed for a 501 given Policy Domain). This would provide insight into policy 502 spoofing or faked policy non-existence. This may be particularly 503 useful for Policy Domains not using DNSSEC, since it would provide 504 sending MTAs an authoritative source for whether a policy is 505 expected for a given domain. 507 o Receive-from restrictions: Policy publishers may wish to also 508 indicate to domains _receiving_ mail from the Policy Domain that 509 all such mail is expected to be sent via TLS. This may allow 510 policy publishers to receive reports indicating sending MTA 511 misconfigurations. However, the security properties of a 512 "receiver-enforced" system differ from those of the current 513 design; in particular, an active man-in-the-middle attacker may be 514 able to exploit misconfigured sending MTAs in a way that would not 515 be possible today with a sender-enforced model. 517 o Cipher and TLS version restrictions: Policy publishers may also 518 wish to restrict TLS negotiation to specific ciphers or TLS 519 versions. 521 8. Appendix 1: Validation Pseudocode 523 policy = policy_from_cache() 524 if not policy or is_expired(policy): 525 policy = policy_from_https_endpoint() // fetch and authenticate! 526 update_cache = true 527 if policy: 528 if invalid_mx_or_tls(policy): // check MX and TLS cert 529 if rua: 530 generate_report() 531 if p_reject(): 532 policy = policy_from_https_endpoint() // fetch and authenticate #2! 533 update_cache = true 534 if invalid_mx_or_tls(policy): 535 reject_message() 536 update_cache = false 537 if update_cache: 538 cache(policy) 540 9. Appendix 2: Domain Owner STS example record 542 9.1. Example 1 544 The owner of example.com wishes to begin using STS with a policy that 545 will solicit aggregate feedback from receivers without affecting how 546 the messages are processed, in order to: 548 o Verify the identity of MXs that handle mail for this domain 550 o Confirm that its legitimate messages are sent over TLS 552 o Verify the validity of the certificates 554 o Determine how many messages would be affected by a strict policy 556 DNS STS policy indicator TXT record: 558 _mta_sts IN TXT ( "v=STSv1; id=randomstr;" ) 560 STS policy served from HTTPS endpoint of the policy (recipient) 561 domain, and is authenticated using Web PKI mechanism. The policy is 562 fetched using HTTP GET method. 564 { 565 "version": "STSv1", 566 "mode": "report", 567 "policy_id": "randomstr", 568 "mx": ["*.mail.example.com"], 569 "max_age": 123456 570 } 572 The policy is authenticated using Web PKI mechanism. 574 10. Appendix 3: DEEP Registration Elements 576 Name: mx-mismatch 577 Description: This indicates that the MX resolved for the recipient domain 578 did not match the MX constraint specified in the policy. 579 Intended Usage: COMMON 580 Reference: RFC XXXX (this document once published) 581 Submitter: Authors of this document 582 Change Controller: IESG 584 Name: certificate-name-mismatch 585 Description: This indicates that the subject CNAME/SAN in the certificate 586 presented by the receiving MX did not match the MX hostname 587 Intended Usage: COMMON 588 Reference: RFC XXXX (this document once published) 589 Submitter: Authors of this document 590 Change Controller: IESG 592 Name: invalid-certificate 593 Description: This indicates that the certificate presented by the receiving MX 594 did not validate according to the policy validation constraint. 595 (Either it was not signed by a trusted CA or did not match the 596 DANE TLSA record for the recipient MX.) 597 Intended Usage: COMMON 598 Reference: RFC XXXX (this document once published) 599 Submitter: Authors of this document 600 Change Controller: IESG 602 Name: certificate-name-constraints-not-permitted 603 Description: The certificate request contains a name that is not listed as 604 permitted in the name constraints extension of the cert issuer. 605 Intended Usage: COMMON 606 Reference: RFC XXXX (this document once published) 607 Submitter: Authors of this document 608 Change Controller: IESG 610 Name: certificate-name-constraints-excluded 611 Description: The certificate request contains a name that is listed as 612 excluded in the name constraints extension of the issuer. 613 Intended Usage: COMMON 614 Reference: RFC XXXX (this document once published) 615 Submitter: Authors of this document 616 Change Controller: IESG 618 Name: expired-certificate 619 Description: This indicates that the certificate has expired. 620 Intended Usage: COMMON 621 Reference: RFC XXXX (this document once published) 622 Submitter: Authors of this document 623 Change Controller: IESG 625 Name: starttls-not-supported 626 Description: This indicates that the recipient MX did not support STARTTLS. 627 Intended Usage: COMMON 628 Reference: RFC XXXX (this document once published) 629 Submitter: Authors of this document 630 Change Controller: IESG 632 Name: tlsa-invalid 633 Description: This indicates a validation error for Policy Domain specifying 634 "tlsa" validation. 635 Intended Usage: COMMON 636 Reference: RFC XXXX (this document once published) 637 Submitter: Authors of this document 638 Change Controller: IESG 640 Name: dnssec-invalid 641 Description: This indicates a failure to validate DNS records for a Policy 642 Domain specifying "tlsa" validation or "dnssec" authentication. 643 Intended Usage: COMMON 644 Reference: RFC XXXX (this document once published) 645 Submitter: Authors of this document 646 Change Controller: IESG 648 Name: sender-does-not-support-validation-method 649 Description: This indicates the sending system can never validate using the 650 requested validation mechanism. 651 Intended Usage: COMMON 652 Reference: RFC XXXX (this document once published) 653 Submitter: Authors of this document 654 Change Controller: IESG 655 11. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 663 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 664 February 2002, . 666 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 667 Rose, "DNS Security Introduction and Requirements", 668 RFC 4033, DOI 10.17487/RFC4033, March 2005, 669 . 671 [RFC4627] Crockford, D., "The application/json Media Type for 672 JavaScript Object Notation (JSON)", RFC 4627, 673 DOI 10.17487/RFC4627, July 2006, 674 . 676 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 677 Specifications: ABNF", STD 68, RFC 5234, 678 DOI 10.17487/RFC5234, January 2008, 679 . 681 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 682 Verification of Domain-Based Application Service Identity 683 within Internet Public Key Infrastructure Using X.509 684 (PKIX) Certificates in the Context of Transport Layer 685 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 686 2011, . 688 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 689 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 690 . 692 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 693 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 694 2015, . 696 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 697 Opportunistic DNS-Based Authentication of Named Entities 698 (DANE) Transport Layer Security (TLS)", RFC 7672, 699 DOI 10.17487/RFC7672, October 2015, 700 . 702 Authors' Addresses 704 Daniel Margolis 705 Google, Inc 707 Email: dmargolis (at) google.com 709 Mark Risher 710 Google, Inc 712 Email: risher (at) google (dot com) 714 Nicolas Lidzborski 715 Google, Inc 717 Email: nlidz (at) google (dot com) 719 Wei Chuang 720 Google, Inc 722 Email: weihaw (at) google (dot com) 724 Brandon Long 725 Google, Inc 727 Email: blong (at) google (dot com) 729 Binu Ramakrishnan 730 Yahoo!, Inc 732 Email: rbinu (at) yahoo-inc (dot com) 734 Alexander Brotman 735 Comcast, Inc 737 Email: alexander_brotman (at) cable.comcast (dot com) 739 Janet Jones 740 Microsoft, Inc 742 Email: janet.jones (at) microsoft (dot com) 743 Franck Martin 744 LinkedIn 746 Email: fmartin (at) linkedin (dot com) 748 Klaus Umbach 749 1&1 Mail & Media Development & Technology GmbH 751 Email: klaus.umbach (at) 1und1 (dot de) 753 Markus Laber 754 1&1 Mail & Media Development & Technology GmbH 756 Email: markus.laber (at) 1und1 (dot de)