idnits 2.17.1 draft-ietf-uta-smtp-tlsrpt-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC6698], [RFC3207]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 2820 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) == Missing Reference: 'SP' is mentioned on line 397, but not defined ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 7435 ** Downref: Normative reference to an Informational RFC: RFC 7489 Summary: 5 errors (**), 0 flaws (~~), 3 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 Google, Inc 4 Intended status: Standards Track A. Brotman 5 Expires: January 9, 2017 Comcast, Inc 6 B. Ramakrishnan 7 Yahoo!, Inc 8 J. Jones 9 Microsoft, Inc 10 M. Risher 11 Google, Inc 12 July 8, 2016 14 SMTP TLS Reporting 15 draft-ietf-uta-smtp-tlsrpt-01 17 Abstract 19 A number of protocols exist for establishing encrypted channels 20 between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE 21 [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can 22 fail due to misconfiguration or active attack, leading to undelivered 23 messages or delivery over unencrypted or unauthenticated channels. 24 This document describes a reporting mechanism and format by which 25 sending systems can share statistics and specific information about 26 potential failures with recipient domains. Recipient domains can 27 then use this information to both detect potential attackers and 28 diagnose unintentional misconfigurations. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 67 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 69 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5 70 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5 71 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Result Types . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1.1. Success Type . . . . . . . . . . . . . . . . . . . . 6 74 4.1.2. Routing Failures . . . . . . . . . . . . . . . . . . 6 75 4.1.3. Negotiation Failures . . . . . . . . . . . . . . . . 6 76 4.1.4. Policy Failures . . . . . . . . . . . . . . . . . . . 7 77 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 7 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 8. Appendix 1: JSON Report Schema . . . . . . . . . . . . . . . 8 81 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 10 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 88 hosts to establish secure SMTP sessions over TLS. The protocol 89 design is based on "Opportunistic Security" (OS) [RFC7435], which 90 provides interoperability for clients that do not support STARTTLS 91 but means that any attacker who can delete parts of the SMTP session 92 (such as the "250 STARTTLS" response) or redirect the entire SMTP 93 session (perhaps by overwriting the resolved MX record of the 94 delivery domain) can perform a downgrade or interception attack. 96 Because such "downgrade attacks" are not necessarily apparent to the 97 receiving MTA, this document defines a mechanism for sending domains 98 to report on failures at multiple parts of the MTA-to-MTA 99 conversation. 101 Recipient domains may also use the mechanisms defined by MTA-STS 102 (TODO: Add ref) or DANE [RFC6698] to publish additional encryption 103 and authentication requirements; this document defines a mechanism 104 for sending domains that are compatible with MTA-STS or DANE to share 105 success and failure statistics with recipient domains. 107 Specifically, this document defines a reporting schema that covers 108 failures in routing, STARTTLS negotiation, and both DANE [RFC6698] 109 and MTA-STS (TODO: Add ref) policy validation errors, and standard 110 TXT record that recipient domains can use to indicate where reports 111 in this format should be sent. 113 This document is intended as a companion to the specification for 114 SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 116 1.1. Terminology 118 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 119 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 120 document, are to be interpreted as described in [RFC2119]. 122 We also define the following terms for further use in this document: 124 o STS Policy: A definition of the expected TLS availability and 125 behavior, as well as the desired actions for a given domain when a 126 sending MTA encounters different results. 128 o TLSRPT Policy: A policy detailing the endpoint to which sending 129 MTAs should deliver reports. 131 o Policy Domain: The domain against which an STS Policy is defined. 133 o Sending MTA: The MTA initiating the delivery of an email message. 135 2. Related Technologies 137 o This document is intended as a companion to the specification for 138 SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 140 o The Public Key Pinning Extension for HTTP [RFC7469] contains a 141 JSON-based definition for reporting individual pin validation 142 failures. 144 o The Domain-based Message Authentication, Reporting, and 145 Conformance (DMARC) [RFC7489] contains an XML-based reporting 146 format for aggregate and detailed email delivery errors. 148 3. Reporting Policy 150 SMTP TLSRPT policies are distributed via DNS from the Policy Domain's 151 zone, as TXT records (similar to DMARC policies) under the name 152 "_smtp_tlsrpt". For example, for the Policy Domain "example.com", 153 the recipient's SMTP STS policy can be retrieved from 154 "_smtp_tlsrpt.example.com". 156 (Future implementations may move to alternate methods of policy 157 discovery or distribution. See the section _Future_ _Work_ for more 158 discussion.) 160 Policies consist of the following directives: 162 o "v": This value MUST be equal to "TLSRPTv1". 164 o "rua": A URI specifying the endpoint to which aggregate 165 information about policy failures should be sent (see the section 166 _Reporting_ _Schema_ for more information). Two URI schemes are 167 supported: "mailto" and "https". 169 * In the case of `https`, reports should be submitted via POST 170 ([@!RFC2818]) to the specified URI. 171 * In the case of `mailto`, reports should be submitted to the specified 172 email address. When sending failure reports via SMTP, sending MTAs 173 MUST NOT honor SMTP STS or DANE TLSA failures. 175 o "ruf": Future use. (There may also be a need for enabling more 176 detailed "forensic" reporting during initial stages of a 177 deployment. To address this, the authors consider the possibility 178 of an optional additional "forensic reporting mode" in which more 179 details--such as certificate chains and MTA banners--may be 180 reported. See the section _Future_ _Work_ for more details.) 182 The formal definition of the "_mta_sts" TXT record, defined using 183 [RFC5234], is as follows: 185 sts-text-record = sts-version *WSP %x3B *WSP sts-id 187 sts-version = "v" *WSP "=" *WSP %x54 %x4C %x53 188 %x52 %x50 %x54 %x76 %x31 190 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) 192 3.1. Example Reporting Policy 194 3.1.1. Report using MAILTO 196 _smtp_tlsrpt.mail.example.com. IN TXT \ 197 "v=TLSRPTv1;rua=mailto:reports@example.com" 199 3.1.2. Report using HTTPS 201 _smtp_tlsrpt.mail.example.com. IN TXT \ 202 "v=TLSRPTv1; \ 203 rua=https://reporting.example.com/v1/tlsrpt" 205 4. Reporting Schema 207 Aggregate reports contain the following fields: 209 o Report metadata: 211 * The organization responsible for the report 213 + Contact information for one or more responsible parties for 214 the contents of the report 216 * A unique identifier for the report 218 * The reporting date range for the report 220 o Policy, consisting of: 222 * One of the following policy types: 224 + The SMTP MTA STS policy applied (as a string) 226 + The DANE TLSA record applied (as a string) * The literal 227 string "no-policy-found", if neither a TLSA nor 229 MTA-STS policy could be found. 231 * The domain for which the policy is applied 233 * The MX host 235 * An identifier for the policy (where applicable) 237 o Aggregate counts, comprising result type, sending MTA IP, 238 receiving MTA hostname, message count, and an optional additional 239 information field containing a URI for recipients to review 240 further information on a failure type. 242 Note that the failure types are non-exclusive; an aggregate report 243 MAY contain overlapping "counts" of failure types where a single send 244 attempt encountered multiple errors. 246 4.1. Result Types 248 The list of result types will start with the minimal set below, and 249 is expected to grow over time based on real-world experience. The 250 initial set is: 252 4.1.1. Success Type 254 o "success": This indicates that the sending MTA was able to 255 successfully negotiate a policy-compliant TLS connection, and 256 serves to provide a "heartbeat" to receiving domains that 257 reporting is functional and tabulating correctly. 259 4.1.2. Routing Failures 261 o "mx-mismatch": This indicates that the MX resolved for the 262 recipient domain did not match the MX constraint specified in the 263 policy. 265 o "certificate-host-mismatch": This indicates that the certificate 266 presented by the receiving MX did not match the MX hostname. 268 4.1.3. Negotiation Failures 270 o "starttls-not-supported": This indicates that the recipient MX did 271 not support STARTTLS. 273 o "invalid-certificate": This indicates that the certificate 274 presented by the receiving MX did not validate. 276 o "certificate-host-mismatch": This indicates that the certificate 277 presented did not adhere to the constraints specified in the STS 278 or DANE policy, e.g. if the CN field did not match the hostname 279 of the MX. 281 o "certificate-name-constraints-not-permitted": The certificate 282 request contains a name that is not listed as permitted in the 283 name constraints extension of the cert issuer. 285 o "certificate-name-constraints-excluded": The certificate request 286 contains a name that is listed as excluded in the name constraints 287 extension of the issuer. 289 o "expired-certificate": This indicates that the certificate has 290 expired. 292 4.1.4. Policy Failures 294 4.1.4.1. DANE-specific Policy Failures 296 o "tlsa-invalid": This indicates a validation error in the TLSA 297 record associated with a DANE policy. 299 o "dnssec-invalid": This indicates a failure to authenticate DNS 300 records for a Policy Domain with a published TLSA record. 302 4.1.4.2. STS-specific Policy Failures 304 o "sts-invalid": This indicates a validation error for the overall 305 MTA-STS policy. 307 o "webpki-invalid": This indicates that the MTA-STS policy could not 308 be authenticated using PKIX validation. 310 5. Report Delivery 312 Note that, when sending failure reports via SMTP, sending MTAs MUST 313 NOT honor SMTP STS or DANE TLSA failures. 315 6. IANA Considerations 317 There are no IANA considerations at this time. 319 7. Security Considerations 321 SMTP TLS Reporting provides transparency into misconfigurations or 322 attempts to intercept or tamper with mail between hosts who support 323 STARTTLS. There are several security risks presented by the 324 existence of this reporting channel: 326 o Flooding of the Aggregate report URI (rua) endpoint: An attacker 327 could flood the endpoint and prevent the receiving domain from 328 accepting additional reports. This type of Denial-of-Service 329 attack would limit visibility into STARTTLS failures, leaving the 330 receiving domain blind to an ongoing attack. 332 o Untrusted content: An attacker could inject malicious code into 333 the report, opening a vulnerability in the receiving domain. 334 Implementers are advised to take precautions against evaluating 335 the contents of the report. 337 o Report snooping: An attacker could create a bogus TLSRPT record to 338 receive statistics about a domain the attacker does not own. 339 Since an attacker able to poison DNS is already able to receive 340 counts of SMTP connections (and, absent DANE or MTA-STS policies, 341 actual SMTP message payloads) today, this does not present a 342 significant new vulnerability. 344 8. Appendix 1: JSON Report Schema 346 The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. 347 Section 3) 349 { 350 "organization-name": organization-name, 351 "date-range": { 352 "start-datetime": date-time, 353 "end-datetime": date-time 354 }, 355 "contact-info": email-address, 356 "report-id": report-id, 357 "policy": { 358 "policy-type": policy-type, 359 "policy-string": policy-string, 360 "policy-domain": domain, 361 "mx-host": mx-host-pattern 362 }, 363 "report-items": [ 364 { 365 "result-type": result-type, 366 "sending-mta-ip": ip-address, 367 "receiving-mx-hostname": receiving-mx-hostname, 368 "message-count": message-count, 369 "additional-information": additional-info-uri 370 } 371 ] 372 } 374 JSON Report Format 376 o "organization-name": The name of the organization responsible for 377 the report. It is provided as a string. 379 o "date-time": The date-time indicates the start- and end-times for 380 the report range. It is provided as a string formatted according 381 to Section 5.6, "Internet Date/Time Format", of [RFC3339]. 383 o "email-address": The contact information for a responsible party 384 of the report. It is provided as a string formatted according to 385 Section 3.4.1, "Addr-Spec", of [RFC5322]. 387 o "report-id": A unique identifier for the report. Report authors 388 may use whatever scheme they prefer to generate a unique 389 identifier. It is provided as a string. 391 o "policy-type": The type of policy that was applied by the sending 392 domain. Presently, the only two valid choices are "tlsa" and 393 "sts". It is provided as a string. 395 o "policy-string": The string serialization of the policy, whether 396 TLSA record or STS policy. Any linefeeds from the original policy 397 MUST be replaced with [SP]. TODO: Help with specifics. 399 o "domain": The Policy Domain upon which the policy was applied. 400 For messages sent to "user@example.com" this field would contain 401 "example.com". It is provided as a string. 403 o "mx-host-pattern": The pattern of MX hostnames from the applied 404 policy. It is provided as a string, and is interpreted in the 405 same manner as the "Checking of Wildcard Certificates" rules in 406 Section 6.4.3 of [RFC6125]. 408 o "result-type": A value from the _Result Types_ section above. 410 o "ip-address": The IP address of the sending MTA that attempted the 411 STARTTLS connection. It is provided as a string representation of 412 an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal 413 notation. 415 o "receiving-mx-hostname": The hostname of the receiving MTA MX 416 record with which the sending MTA attempted to negotiate a 417 STARTTLS connection. 419 o "message-count": The number of (attempted) messages that match the 420 relevant "result-type" for this section. 422 o "additional-info-uri": An optional URI pointing to additional 423 information around the relevant "result-type". For example, this 424 URI might host the complete certificate chain presented during an 425 attempted STARTTLS session. 427 9. Appendix 2: Example JSON Report 429 { 430 "organization-name": "Company-X", 431 "date-range": { 432 "start-datetime": "2016-04-01T00:00:00Z", 433 "end-datetime": "2016-04-01T23:59:59Z" 434 }, 435 "contact-info": "sts-reporting@company-x.com", 436 "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", 437 "policy": { 438 "policy-type": "sts", 439 "policy-string": "TODO: Add me", 440 "policy-domain": "company-y.com", 441 "mx-host": "*.mail.company-y.com" 442 }, 443 "report-items": [{ 444 "result-type": "ExpiredCertificate", 445 "sending-mta-ip": "98.136.216.25", 446 "receiving-mx-hostname": "mx1.mail.company-y.com", 447 "message-count": 100 448 }, { 449 "result-type": "StarttlsNotSupported", 450 "sending-mta-ip": "98.22.33.99", 451 "receiving-mx-hostname": "mx2.mail.company-y.com", 452 "message-count": 200, 453 "additional-information": "hxxps://reports.company-x.com/ 454 report_info?id=5065427c-23d3#StarttlsNotSupported" 455 }] 456 } 458 Example JSON report for a messages from Company-X to Company-Y, where 459 100 messages were attempted to Company Y servers with an expired 460 certificate and 200 messages were attempted to Company Y servers that 461 did not successfully respond to the STARTTLS command. 463 10. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 471 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 472 February 2002, . 474 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 475 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 476 . 478 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 479 Specifications: ABNF", STD 68, RFC 5234, 480 DOI 10.17487/RFC5234, January 2008, 481 . 483 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 484 DOI 10.17487/RFC5322, October 2008, 485 . 487 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 488 Verification of Domain-Based Application Service Identity 489 within Internet Public Key Infrastructure Using X.509 490 (PKIX) Certificates in the Context of Transport Layer 491 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 492 2011, . 494 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 495 of Named Entities (DANE) Transport Layer Security (TLS) 496 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 497 2012, . 499 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 500 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 501 December 2014, . 503 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 504 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 505 2015, . 507 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 508 Message Authentication, Reporting, and Conformance 509 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 510 . 512 Authors' Addresses 514 Daniel Margolis 515 Google, Inc 517 Email: dmargolis (at) google.com 518 Alexander Brotman 519 Comcast, Inc 521 Email: alexander_brotman (at) cable.comcast (dot com) 523 Binu Ramakrishnan 524 Yahoo!, Inc 526 Email: rbinu (at) yahoo-inc (dot com) 528 Janet Jones 529 Microsoft, Inc 531 Email: janet.jones (at) microsoft (dot com) 533 Mark Risher 534 Google, Inc 536 Email: risher (at) google (dot com)