1 ../mox-/config.go:554 ../mox-/config.go:1570
2
3
4
5
6
7Internet Engineering Task Force (IETF) D. Margolis
8Request for Comments: 8460 Google, Inc.
9Category: Standards Track A. Brotman
10ISSN: 2070-1721 Comcast, Inc.
11 B. Ramakrishnan
12 Oath, Inc.
13 J. Jones
14 Microsoft, Inc.
15 M. Risher
16 Google, Inc.
17 September 2018
18
19
20 SMTP TLS Reporting
21
22Abstract
23
24 A number of protocols exist for establishing encrypted channels
25 between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-
26 Based Authentication of Named Entities (DANE) TLSA, and MTA Strict
27 Transport Security (MTA-STS). These protocols can fail due to
28 misconfiguration or active attack, leading to undelivered messages or
29 delivery over unencrypted or unauthenticated channels. This document
30 describes a reporting mechanism and format by which sending systems
31 can share statistics and specific information about potential
32 failures with recipient domains. Recipient domains can then use this
33 information to both detect potential attacks and diagnose
34 unintentional misconfigurations.
35
36Status of This Memo
37
38 This is an Internet Standards Track document.
39
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 Internet Standards is available in Section 2 of RFC 7841.
45
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 https://www.rfc-editor.org/info/rfc8460.
49
50
51
52
53
54
55
56
57
58Margolis, et al. Standards Track [Page 1]
59
60RFC 8460 SMTP TLS Reporting September 2018
61
62
63Copyright Notice
64
65 Copyright (c) 2018 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (https://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114Margolis, et al. Standards Track [Page 2]
115
116RFC 8460 SMTP TLS Reporting September 2018
117
118
119Table of Contents
120
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
123 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
124 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6
125 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8
126 3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8
127 3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8
128 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8
129 4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9
130 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10
131 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10
132 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10
133 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10
134 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
135 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11
136 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
137 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12
138 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12
139 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15
140 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
141 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16
142 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17
143 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17
144 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19
145 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19
146 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20
147 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20
148 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
149 6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
150 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21
151 6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22
152 6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23
153 6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24
154 6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25
155 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
156 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
157 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
158 9.1. Normative References . . . . . . . . . . . . . . . . . . 28
159 9.2. Informative References . . . . . . . . . . . . . . . . . 30
160 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32
161 A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32
162 A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32
163 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32
164 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
166
167
168
169
170Margolis, et al. Standards Track [Page 3]
171
172RFC 8460 SMTP TLS Reporting September 2018
173
174
1751. Introduction
176
177 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
178 hosts to establish secure SMTP sessions over TLS. The protocol
179 design uses an approach that has come to be known as "Opportunistic
180 Security" (OS) [RFC7435]. This method maintains interoperability
181 with clients that do not support STARTTLS, but it means that any
182 attacker could potentially eavesdrop on a session. An attacker could
183 perform a downgrade or interception attack by deleting parts of the
184 SMTP session (such as the "250 STARTTLS" response) or redirect the
185 entire SMTP session (perhaps by overwriting the resolved MX record of
186 the delivery domain).
187
188 Because such "downgrade attacks" are not necessarily apparent to the
189 receiving MTA, this document defines a mechanism for sending domains
190 to report on failures at multiple stages of the MTA-to-MTA
191 conversation.
192
193 Recipient domains may also use the mechanisms defined by MTA-STS
194 [RFC8461] or DANE [RFC6698] to publish additional encryption and
195 authentication requirements; this document defines a mechanism for
196 sending domains that are compatible with MTA-STS or DANE to share
197 success and failure statistics with recipient domains.
198
199 Specifically, this document defines a reporting schema that covers
200 failures in routing, DNS resolution, and STARTTLS negotiation; policy
201 validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and
202 a standard TXT record that recipient domains can use to indicate
203 where reports in this format should be sent. The report can also
204 serve as a heartbeat to indicate that systems are successfully
205 negotiating TLS during sessions as expected.
206
207 This document is intended as a companion to the specification for
208 SMTP MTA-STS [RFC8461] and adds reporting abilities for those
209 implementing DANE [RFC7672].
210
2111.1. Terminology
212
213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
215 "OPTIONAL" in this document are to be interpreted as described in
216 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
217 capitals, as shown here.
218
219
220
221
222
223
224
225
226Margolis, et al. Standards Track [Page 4]
227
228RFC 8460 SMTP TLS Reporting September 2018
229
230
231 We also define the following terms for further use in this document:
232
233 o MTA-STS Policy: A mechanism by which administrators can specify
234 the expected TLS availability, presented identity, and desired
235 actions for a given email recipient domain. MTA-STS is defined in
236 [RFC8461].
237
238 o DANE Policy: A mechanism by which administrators can use DNSSEC to
239 commit an MTA to support STARTTLS and to publish criteria to be
240 used to validate its presented certificates. DANE for SMTP is
241 defined in [RFC7672], with the base specification defined in
242 [RFC6698] (and updated by [RFC7671]).
243
244 o TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to
245 which Sending MTAs should deliver reports.
246
247 o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a
248 DANE policy is defined. For TLSRPT and MTA-STS, this is typically
249 the same as the envelope recipient domain [RFC5321], but when mail
250 is routed to a "smarthost" gateway by local policy, the
251 "smarthost" domain name is used instead. For DANE, the Policy ../tlsrpt/report.go:127
252 Domain is the "TLSA base domain" of the receiving SMTP server as
253 described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698.
254
255 o Sending MTA: The MTA initiating the relay of an email message.
256
257 o Aggregate Report URI (rua): A comma-separated list of locations
258 where the report is to be submitted.
259
260 o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
261 syntax, defined in [RFC5234] and [RFC7405].
262
2632. Related Technologies
264
265 o This document is intended as a companion to the specification for
266 SMTP MTA-STS [RFC8461].
267
268 o SMTP TLSRPT defines a mechanism for sending domains that are
269 compatible with MTA-STS or DANE to share success and failure
270 statistics with recipient domains. DANE is defined in [RFC6698],
271 and MTA-STS is defined in [RFC8461].
272
273
274
275
276
277
278
279
280
281
282Margolis, et al. Standards Track [Page 5]
283
284RFC 8460 SMTP TLS Reporting September 2018
285
286
2873. Reporting Policy
288
289 A domain publishes a record to its DNS indicating that it wishes to
290 receive reports. These SMTP TLSRPT policies are distributed via DNS
291 from the Policy Domain's zone as TXT records (similar to Domain-based
292 Message Authentication, Reporting, and Conformance (DMARC) policies)
293 under the name "_smtp._tls". For example, for the Policy Domain
294 "example.com", the recipient's TLSRPT policy can be retrieved from
295 "_smtp._tls.example.com".
296
297 Policies consist of the following directives:
298
299 o "v": This document defines version 1 of TLSRPT, for which this
300 value MUST be equal to "TLSRPTv1". Other versions may be defined
301 in later documents.
302
303 o "rua": A URI specifying the endpoint to which aggregate
304 information about policy validation results should be sent (see
305 Section 4, "Reporting Schema", for more information). Two URI
306 schemes are supported: "mailto" and "https". As with DMARC
307 [RFC7489], the Policy Domain can specify a comma-separated list of
308 URIs.
309
310 o In the case of "https", reports should be submitted via POST todo spec: ../tlsrptsend/send.go:369
311 [RFC7231] to the specified URI. Report submitters MAY ignore
312 certificate validation errors when submitting reports via HTTPS
313 POST.
314
315 o In the case of "mailto", reports should be submitted to the
316 specified email address [RFC6068]. When sending failure reports ../smtpserver/server.go:819
317 via SMTP, Sending MTAs MUST deliver reports despite any TLS- 8460:1050 ../tlsrptsend/send.go:598 ../tlsrptsend/send.go:650
318 related failures and SHOULD NOT include this SMTP session in the ../tlsrptdb/result.go:44
319 next report. This may mean that the reports are delivered
320 unencrypted. Reports sent via SMTP MUST contain a valid 8460:1055 ../smtpserver/analyze.go:329 ../tlsrptsend/send.go:368
321 DomainKeys Identified Mail (DKIM) [RFC6376] signature by the
322 reporting domain. Reports lacking such a signature MUST be ../smtpserver/analyze.go:322 todo spec: ../tlsrptsend/send.go:292
323 ignored by the recipient. DKIM signatures MUST NOT use the "l="
324 attribute to limit the body length used in the signature. This
325 ensures attackers cannot append extraneous or misleading data to a
326 report without breaking the signature. The DKIM TXT record SHOULD ../smtpserver/analyze.go:338
327 contain the appropriate service type declaration, "s=tlsrpt". If
328 not present, the receiving system MAY ignore reports lacking that
329 service type.
330
331 Sample DKIM record:
332
333 dkim_selector._domainkey.example.com TXT
334 "v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
335
336
337
338Margolis, et al. Standards Track [Page 6]
339
340RFC 8460 SMTP TLS Reporting September 2018
341
342
343 The formal definition of the "_smtp._tls" TXT record, defined using
344 [RFC5234] and [RFC7405], is as follows:
345
346 tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
347 [field-delim]
348
349 field-delim = *WSP ";" *WSP
350
351 tlsrpt-field = tlsrpt-rua / ; Note that the
352 tlsrpt-extension ; tlsrpt-rua record is
353 ; required.
354
355 tlsrpt-version = %s"v=TLSRPTv1"
356
357 tlsrpt-rua = %s"rua="
358 tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) ../tlsrpt/parse.go:229
359
360 tlsrpt-uri = URI ../tlsrpt/parse.go:241
361 ; "URI" is imported from [RFC3986];
362 ; commas (ASCII 0x2C), exclamation
363 ; points (ASCII 0x21), and semicolons
364 ; (ASCII 0x3B) MUST be encoded
365
366 tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
367
368 tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / ../tlsrpt/parse.go:187
369 DIGIT / "_" / "-" / ".")
370
371 tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ../tlsrpt/parse.go:194
372 ; chars excluding "=", ";", SP, and control
373 ; chars
374
375 If multiple TXT records for "_smtp._tls" are returned by the ../tlsrpt/lookup.go:66
376 resolver, records that do not begin with "v=TLSRPTv1;" are discarded.
377 If the number of resulting records is not one, senders MUST assume
378 the recipient domain does not implement TLSRPT. If the resulting TXT
379 record contains multiple strings (as described in Section 3.3 of
380 [RFC7208]), then the record MUST be treated as if those strings are
381 concatenated without adding spaces.
382
383 The record supports the ability to declare more than one rua, and if ../tlsrpt/parse.go:26
384 there exists more than one, the reporter MAY attempt to deliver to
385 each of the supported rua destinations. A receiver MAY opt to only
386 attempt delivery to one of the endpoints; however, the report SHOULD
387 NOT be considered successfully delivered until one of the endpoints
388 accepts delivery of the report.
389
390
391
392
393
394Margolis, et al. Standards Track [Page 7]
395
396RFC 8460 SMTP TLS Reporting September 2018
397
398
399 Parsers MUST accept TXT records that are syntactically valid (i.e., ../tlsrpt/parse.go:201
400 valid key/value pairs separated by semicolons) and implement a
401 superset of this specification, in which case unknown fields SHALL be
402 ignored.
403
4043.1. Example Reporting Policy
405
4063.1.1. Report Using MAILTO
407
408 _smtp._tls.example.com. IN TXT \
409 "v=TLSRPTv1;rua=mailto:reports@example.com"
410
4113.1.2. Report Using HTTPS
412
413 _smtp._tls.example.com. IN TXT \
414 "v=TLSRPTv1; \
415 rua=https://reporting.example.com/v1/tlsrpt"
416
4174. Reporting Schema
418
419 The report is composed as a plaintext file encoded in the Internet
420 JSON (I-JSON) format [RFC7493].
421
422 Aggregate reports contain the following fields:
423
424 o Report metadata:
425
426 * The organization responsible for the report
427
428 * Contact information for one or more responsible parties for the
429 contents of the report
430
431 * A unique identifier for the report
432
433 * The reporting date range for the report
434
435 o Policy, consisting of:
436
437 * One of the following policy types: (1) the MTA-STS Policy todo spec: ../tlsrpt/report.go:232
438 applied (as a string), (2) the DANE TLSA record applied (as a
439 string, with each RR entry of the RRset listed and separated by
440 a semicolon), and (3) the literal string "no-policy-found", if 8460:697 todo spec: ../queue/queue.go:1583 todo spec: ../tlsrpt/report.go:261
441 neither a DANE nor MTA-STS Policy could be found. 8460:463 todo spec: ../tlsrptsend/send.go:12
442
443 * The domain for which the policy is applied
444
445 * The MX host
446
447
448
449
450Margolis, et al. Standards Track [Page 8]
451
452RFC 8460 SMTP TLS Reporting September 2018
453
454
455 o Aggregate counts, comprising result type, Sending MTA IP,
456 receiving MTA hostname, session count, and an optional additional
457 information field containing a URI for recipients to review
458 further information on a failure type.
459
460 Note that the failure types are non-exclusive; an aggregate report
461 may contain overlapping "counts" of failure types when a single send
462 attempt encountered multiple errors. Reporters may report multiple
463 applied policies (for example, an MTA-STS Policy and a DANE TLSA 8460:441 todo spec: ../tlsrptsend/send.go:12
464 record for the same domain and MX). Because of this, even in the
465 case where only a single policy was applied, the "policies" field of
466 the report body MUST be an array and not a singular value.
467
468 In the case of multiple failure types, the "failure-details" array
469 would contain multiple entries. Each entry would have its own set of
470 information pertaining to that failure type.
471
4724.1. Report Time Frame
473
474 The report SHOULD cover a full day, from 00:00-24:00 UTC. This ../tlsrptdb/result.go:29
475 should allow for easier correlation of failure events. To avoid
476 unintentionally overloading the system processing the reports, the
477 reports should be delivered after some delay, perhaps several hours.
478
479 As an example, a sending site might want to introduce a random delay ../tlsrptsend/send.go:191
480 of up to four hours:
481
482 func generate_sleep_delay() {
483 min_delay = 1
484 max_delay = 14400
485 rand = random(min_delay, max_delay)
486 return rand
487 }
488
489 func generate_report(policy_domain) {
490 do_rpt_work(policy_domain)
491 send_rpt(policy_domain)
492 }
493
494 func generate_tlsrpt() {
495 sleep(generate_sleep_delay())
496 for policy_domain in list_of_tlsrpt_enabled_domains {
497 generate_report(policy_domain)
498 }
499 }
500
501
502
503
504
505
506Margolis, et al. Standards Track [Page 9]
507
508RFC 8460 SMTP TLS Reporting September 2018
509
510
5114.2. Delivery Summary
512
5134.2.1. Success Count
514
515 o "total-successful-session-count": This indicates that the Sending ../smtpclient/client.go:831
516 MTA was able to successfully negotiate a policy-compliant TLS
517 connection and serves to provide a "heartbeat" to receiving
518 domains that signifies reporting is functional and tabulating
519 correctly. This field contains an aggregate count of successful
520 connections for the reporting system.
521
5224.2.2. Failure Count
523
524 o "total-failure-session-count": This indicates that the Sending MTA ../smtpclient/client.go:809
525 was unable to successfully establish a connection with the
526 receiving platform. Section 4.3, "Result Types", will elaborate
527 on the failed negotiation attempts. This field contains an
528 aggregate count of failed connections.
529
5304.3. Result Types
531
532 The list of result types will start with the minimal set below and is
533 expected to grow over time based on real-world experience. The
534 initial set is outlined in Sections 4.3.1 to 4.3.4:
535
5364.3.1. Negotiation Failures
537
538 o "starttls-not-supported": This indicates that the recipient MX did ../smtpclient/client.go:836
539 not support STARTTLS.
540
541 o "certificate-host-mismatch": This indicates that the certificate todo spec: ../smtpclient/client.go:370 ../tlsrpt/report.go:377
542 presented did not adhere to the constraints specified in the MTA-
543 STS or DANE policy, e.g., if the MX hostname does not match any
544 identities listed in the subject alternative name (SAN) [RFC5280].
545
546 o "certificate-expired": This indicates that the certificate has ../tlsrpt/report.go:367
547 expired.
548
549 o "certificate-not-trusted": This is a label that covers multiple ../tlsrpt/report.go:374 ../tlsrpt/report.go:380 ../tlsrpt/report.go:383
550 certificate-related failures that include, but are not limited to,
551 errors such as untrusted/unknown certification authorities (CAs),
552 certificate name constraints, certificate chain errors, etc. When
553 using this declaration, the reporting MTA SHOULD utilize the
554 "failure-reason-code" to provide more information to the receiving
555 entity.
556
557
558
559
560
561
562Margolis, et al. Standards Track [Page 10]
563
564RFC 8460 SMTP TLS Reporting September 2018
565
566
567 o "validation-failure": This indicates a general failure for a ../queue/direct.go:150 ../queue/direct.go:205 ../queue/direct.go:492 ../tlsrpt/report.go:387 ../tlsrpt/report.go:403 ../tlsrpt/report.go:413
568 reason not matching a category above. When using this
569 declaration, the reporting MTA SHOULD utilize the "failure-reason-
570 code" to provide more information to the receiving entity.
571
5724.3.2. Policy Failures
573
5744.3.2.1. DANE-Specific Policy Failures
575
576 o "tlsa-invalid": This indicates a validation error in the TLSA ../queue/direct.go:534
577 record associated with a DANE policy. None of the records in the
578 RRset were found to be valid.
579
580 o "dnssec-invalid": This indicates that no valid records were ../mtasts/mtasts.go:149 ../queue/direct.go:147 ../queue/direct.go:558
581 returned from the recursive resolver.
582
583 o "dane-required": This indicates that the sending system is
584 configured to require DANE TLSA records for all the MX hosts of
585 the destination domain, but no DNSSEC-validated TLSA records were
586 present for the MX host that is the subject of the report.
587 Mandatory DANE for SMTP is described in Section 6 of [RFC7672].
588 Such policies may be created by mutual agreement between two
589 organizations that frequently exchange sensitive content via
590 email.
591
5924.3.2.2. MTA-STS-specific Policy Failures
593
594 o "sts-policy-fetch-error": This indicates a failure to retrieve an ../mtastsdb/db.go:263 ../mtastsdb/db.go:291 ../mtastsdb/db.go:316 ../mtastsdb/db.go:370
595 MTA-STS policy, for example, because the policy host is
596 unreachable.
597
598 o "sts-policy-invalid": This indicates a validation error for the ../mtastsdb/db.go:367
599 overall MTA-STS Policy.
600
601 o "sts-webpki-invalid": This indicates that the MTA-STS Policy could ../mtastsdb/db.go:360
602 not be authenticated using PKIX validation.
603
6044.3.3. General Failures
605
606 When a negotiation failure cannot be categorized into one of the
607 "Negotiation Failures" stated above, the reporter SHOULD use the
608 "validation-failure" category. As TLS grows and becomes more
609 complex, new mechanisms may not be easily categorized. This allows
610 for a generic feedback category. When this category is used, the ../queue/direct.go:204 ../tlsrpt/report.go:386 ../tlsrpt/report.go:412
611 reporter SHOULD also use "failure-reason-code" to give some feedback
612 to the receiving entity. This is intended to be a short text field,
613 and the contents of the field should be an error code or error text,
614 such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".
615
616
617
618Margolis, et al. Standards Track [Page 11]
619
620RFC 8460 SMTP TLS Reporting September 2018
621
622
6234.3.4. Transient Failures
624
625 Transient errors due to too-busy networks, TCP timeouts, etc., are ../tlsrpt/report.go:410
626 not required to be reported.
627
6284.4. JSON Report Schema ../tlsrpt/report.go:31
629
630 The JSON schema is derived from the HTTP Public Key Pinning (HPKP)
631 JSON schema; see Section 3 of [RFC7469].
632
633 {
634 "organization-name": organization-name,
635 "date-range": {
636 "start-datetime": date-time,
637 "end-datetime": date-time
638 },
639 "contact-info": email-address,
640 "report-id": report-id,
641 "policies": [{
642 "policy": {
643 "policy-type": policy-type,
644 "policy-string": policy-string,
645 "policy-domain": domain,
646 "mx-host": mx-host-pattern
647 },
648 "summary": {
649 "total-successful-session-count": total-successful-session-count,
650 "total-failure-session-count": total-failure-session-count
651 },
652 "failure-details": [
653 {
654 "result-type": result-type,
655 "sending-mta-ip": ip-address,
656 "receiving-mx-hostname": receiving-mx-hostname,
657 "receiving-mx-helo": receiving-mx-helo,
658 "receiving-ip": receiving-ip,
659 "failed-session-count": failed-session-count,
660 "additional-information": additional-info-uri,
661 "failure-reason-code": failure-reason-code
662 }
663 ]
664 }
665 ]
666 }
667
668
669 JSON Report Format
670
671
672
673
674Margolis, et al. Standards Track [Page 12]
675
676RFC 8460 SMTP TLS Reporting September 2018
677
678
679 o "organization-name": The name of the organization responsible for
680 the report. It is provided as a string.
681
682 o "date-time": The date-time indicates the start and end times for 3339:415 ../tlsrpt/report.go:199
683 the report range. It is provided as a string formatted according
684 to "Internet Date/Time Format", Section 5.6 of [RFC3339]. The
685 report should be for a full UTC day, 00:00-24:00.
686
687 o "email-address": The contact information for the party responsible
688 for the report. It is provided as a string formatted according to
689 "Addr-Spec Specification", Section 3.4.1 of [RFC5322].
690
691 o "report-id": A unique identifier for the report. Report authors 8460:968 8460:1772 todo spec: ../tlsrptsend/send.go:415
692 may use whatever scheme they prefer to generate a unique
693 identifier. It is provided as a string.
694
695 o "policy-type": The type of policy that was applied by the sending
696 domain. Presently, the only three valid choices are "tlsa",
697 "sts", and the literal string "no-policy-found". It is provided 8460:440 todo spec: ../tlsrpt/report.go:261
698 as a string.
699
700 o "policy-string": An encoding of the applied policy as a JSON array
701 of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or
702 an MTA-STS Policy. Examples follow in the next section.
703
704 o "domain": The Policy Domain against which the MTA-STS or DANE ../tlsrpt/report.go:237
705 policy is defined. In the case of Internationalized Domain Names
706 [RFC5891], the domain MUST consist of the Punycode-encoded
707 A-labels [RFC3492] and not the U-labels.
708
709 o "mx-host-pattern": In the case where "policy-type" is "sts", it's
710 the pattern of MX hostnames from the applied policy. It is
711 provided as a JSON array of strings and is interpreted in the same
712 manner as the rules in "MX Host Validation"; see Section 4.1 of
713 [RFC8461]. In the case of Internationalized Domain Names
714 [RFC5891], the domain MUST consist of the Punycode-encoded
715 A-labels [RFC3492] and not the U-labels.
716
717 o "result-type": A value from Section 4.3, "Result Types", above.
718
719 o "ip-address": The IP address of the Sending MTA that attempted the todo spec: ../tlsrpt/report.go:298
720 STARTTLS connection. It is provided as a string representation of
721 an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or
722 colon-hexadecimal notation.
723
724 o "receiving-mx-hostname": The hostname of the receiving MTA MX
725 record with which the Sending MTA attempted to negotiate a
726 STARTTLS connection.
727
728
729
730Margolis, et al. Standards Track [Page 13]
731
732RFC 8460 SMTP TLS Reporting September 2018
733
734
735 o "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO
736 (EHLO) string from the banner announced during the reported
737 session.
738
739 o "receiving-ip": The destination IP address that was used when
740 creating the outbound session. It is provided as a string
741 representation of an IPv4 (see below) or IPv6 [RFC5952] address in
742 dot-decimal or colon-hexadecimal notation.
743
744 o "total-successful-session-count": The aggregate count (an integer,
745 encoded as a JSON number) of successfully negotiated TLS-enabled
746 connections to the receiving site.
747
748 o "total-failure-session-count": The aggregate count (an integer,
749 encoded as a JSON number) of failures to negotiate a TLS-enabled
750 connection to the receiving site.
751
752 o "failed-session-count": The number of (attempted) sessions that
753 match the relevant "result-type" for this section (an integer,
754 encoded as a JSON number).
755
756 o "additional-info-uri" (optional): A URI [RFC3986] that points to
757 additional information around the relevant "result-type". For
758 example, this URI might host the complete certificate chain
759 presented during an attempted STARTTLS session.
760
761 o "failure-reason-code": A text field to include a TLS-related error
762 code or error message.
763
764 For report purposes, an IPv4 address is defined via the following
765 ABNF:
766
767 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
768 dec-octet = DIGIT ; 0-9
769 / %x31-39 DIGIT ; 10-99
770 / "1" 2DIGIT ; 100-199
771 / "2" %x30-34 DIGIT ; 200-249
772 / "25" %x30-35 ; 250-255
773
774 And an IPv6 address is defined via the following ABNF:
775
776
777 IPv6address = <as defined in [RFC5954]>
778
779
780
781
782
783
784
785
786Margolis, et al. Standards Track [Page 14]
787
788RFC 8460 SMTP TLS Reporting September 2018
789
790
7914.5. Policy Samples
792
793 Part of the report body includes the policy that is applied when
794 attempting relay to the destination.
795
796 For DANE TLSA policies, this is a JSON array of strings each
797 representing the RDATA of a single TLSA resource record as a space-
798 separated list of its four TLSA fields; the fields are in
799 presentation format (defined in [RFC6698], Section 2.2) with no
800 internal spaces or grouping parentheses:
801
802 [
803 "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513
804 D747D1D085D",
805 "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513
806 D747D1D1234"
807 ]
808
809 For MTA-STS policies, this is an array of JSON strings that
810 represents the policy that is declared by the receiving site,
811 including any errors that may be present. Note that where there are
812 multiple "mx" values, they must be listed as separate "mx" elements
813 in the policy array rather than as a single nested "mx" sub-array.
814
815 [
816 "version: STSv1",
817 "mode: testing",
818 "mx: mx1.example.com",
819 "mx: mx2.example.com",
820 "mx: mx.backup-example.com",
821 "max_age: 604800"
822 ]
823
8245. Report Delivery
825
826 Reports can be delivered either via SMTP (as an email message) or via
827 HTTP POST.
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842Margolis, et al. Standards Track [Page 15]
843
844RFC 8460 SMTP TLS Reporting September 2018
845
846
8475.1. Report Filename
848
849 The filename is RECOMMENDED to be constructed using the following ../tlsrptsend/send.go:529
850 ABNF:
851
852 filename = sender "!" policy-domain "!" begin-timestamp
853 "!" end-timestamp [ "!" unique-id ] "." extension
854
855 unique-id = 1*(ALPHA / DIGIT)
856
857 sender = domain ; from [RFC5321] -- this is used
858 ; as the domain for the `contact-info`
859 ; address in the report body.
860 ; In the case of Internationalized Domain
861 ; Names [RFC5891], the domain MUST consist of
862 ; the Punycode-encoded A-labels [RFC3492] and
863 ; not the U-labels.
864
865 policy-domain = domain
866 ; In the case of Internationalized Domain
867 ; Names [RFC5891], the domain MUST consist of
868 ; the Punycode-encoded A-labels [RFC3492] and
869 ; not the U-labels.
870
871 begin-timestamp = 1*DIGIT
872 ; seconds since 00:00:00 UTC January 1, 1970
873 ; indicating start of the time range contained
874 ; in the report
875
876 end-timestamp = 1*DIGIT
877 ; seconds since 00:00:00 UTC January 1, 1970
878 ; indicating end of the time range contained
879 ; in the report
880
881 extension = "json" / "json.gz"
882
883
884 The extension MUST be "json" for a plain JSON file or "json.gz" for a
885 JSON file compressed using gzip.
886
887 "unique-id" allows an optional unique ID generated by the Sending MTA
888 to distinguish among multiple reports generated simultaneously by
889 different sources for the same Policy Domain. For example, this is a
890 possible filename for a compressed report to the Policy Domain
891 "example.net" from the Sending MTA "mail.sndr.example.com":
892
893 "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
894
895
896
897
898Margolis, et al. Standards Track [Page 16]
899
900RFC 8460 SMTP TLS Reporting September 2018
901
902
9035.2. Compression
904
905 The report SHOULD be subjected to gzip [RFC1952] compression for both ../tlsrpt/report.go:456 ../tlsrptsend/send.go:487
906 email and HTTPS transport. Declining to apply compression can cause
907 the report to be too large for a receiver to process (a commonly
908 observed receiver limit is ten megabytes); compressing the file
909 increases the chances of acceptance of the report at some
910 computational cost.
911
9125.3. Email Transport
913
914 The report MAY be delivered by email. To make the reports machine-
915 parsable for the receivers, we define a top-level media type
916 "multipart/report" with a new parameter "report-type="tlsrpt"". ../tlsrptsend/send.go:660
917 Inside it, there are two parts: The first part is human readable, ../tlsrptsend/send.go:516
918 typically "text/plain", and the second part is machine readable with
919 a new media type defined called "application/tlsrpt+json". If
920 compressed, the report should use the media type "application/
921 tlsrpt+gzip".
922
923 In addition, the following two new top-level message header fields
924 are defined:
925
926 "TLS-Report-Domain: Receiver-Domain" ../tlsrptsend/send.go:647
927
928 "TLS-Report-Submitter: Sender-Domain"
929
930 The "TLS-Report-Submitter" value MUST match the value found in the
931 domain [RFC5321] of the "contact-info" from the report body. These
932 message header fields MUST be included and should allow for easy
933 searching for all reports submitted by a reporting domain or a
934 particular submitter, for example, in IMAP [RFC3501]:
935
936 "s SEARCH HEADER "TLS-Report-Domain" "example.com""
937
938 It is presumed that the aggregate reporting address will be equipped
939 to process new message header fields and extract MIME parts with the
940 prescribed media type and filename, and ignore the rest. These ../tlsrptsend/send.go:696
941 additional headers SHOULD be included in the DKIM [RFC6376] signature
942 for the message.
943
944
945
946
947
948
949
950
951
952
953
954Margolis, et al. Standards Track [Page 17]
955
956RFC 8460 SMTP TLS Reporting September 2018
957
958
959 The RFC5322.Subject field for report submissions SHOULD conform to ../tlsrptsend/send.go:513
960 the following ABNF:
961
962 tlsrpt-subject = %s"Report" FWS ; "Report"
963 %s"Domain:" FWS ; "Domain:"
964 domain-name FWS ; per [RFC6376]
965 %s"Submitter:" FWS ; "Submitter:"
966 domain-name FWS ; per [RFC6376]
967 %s"Report-ID:" FWS ; "Report-ID:
968 "<" id-left "@" id-right ">" ; per [RFC5322] 8460:1772 8460:691 todo spec: ../tlsrptsend/send.go:415
969 [CFWS] ; per [RFC5322]
970 ; (as with FWS)
971
972 The first domain-name indicates the DNS domain name about which the
973 report was generated. The second domain-name indicates the DNS
974 domain name representing the Sending MTA generating the report. The
975 purpose of the "Report-ID:" portion of the field is to enable the
976 Policy Domain to identify and ignore duplicate reports that might be
977 sent by a Sending MTA.
978
979 For instance, this is a possible Subject field for a report to the
980 Policy Domain "example.net" from the Sending MTA
981 "mail.sender.example.com". It is line-wrapped as allowed by
982 [RFC5322]:
983
984 Subject: Report Domain: example.net
985 Submitter: mail.sender.example.com
986 Report-ID: <735ff.e317+bf22029@mailexample.net>
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010Margolis, et al. Standards Track [Page 18]
1011
1012RFC 8460 SMTP TLS Reporting September 2018
1013
1014
10155.3.1. Example Report ../tlsrpt/report_test.go:66
1016
1017 From: tlsrpt@mail.sender.example.com todo spec: ../tlsrptsend/send.go:13
1018 Date: Fri, May 09 2017 16:54:30 -0800
1019 To: mts-sts-tlsrpt@example.net
1020 Subject: Report Domain: example.net
1021 Submitter: mail.sender.example.com
1022 Report-ID: <735ff.e317+bf22029@example.net>
1023 TLS-Report-Domain: example.net
1024 TLS-Report-Submitter: mail.sender.example.com
1025 MIME-Version: 1.0
1026 Content-Type: multipart/report; report-type="tlsrpt";
1027 boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
1028 Content-Language: en-us
1029
1030 This is a multipart message in MIME format.
1031
1032 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
1033 Content-Type: text/plain; charset="us-ascii"
1034 Content-Transfer-Encoding: 7bit
1035
1036 This is an aggregate TLS report from mail.sender.example.com
1037
1038 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
1039 Content-Type: application/tlsrpt+gzip
1040 Content-Transfer-Encoding: base64
1041 Content-Disposition: attachment;
1042 filename="mail.sender.example!example.com!
1043 1013662812!1013749130.json.gz"
1044
1045 <gzipped content of report>
1046
1047 ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
1048 ...
1049
1050 Note that, when sending failure reports via SMTP, Sending MTAs MUST 8460:317 ../tlsrptsend/send.go:598 ../tlsrptsend/send.go:650
1051 NOT honor MTA-STS or DANE TLSA failures.
1052
10535.4. HTTPS Transport
1054
1055 The report MAY be delivered by POST to HTTPS. If compressed, the 8460:320 ../tlsrptsend/send.go:368
1056 report SHOULD use the media type "application/tlsrpt+gzip"; otherwise
1057 it SHOULD use the media type "application/tlsrpt+json" (see
1058 Section 6, "IANA Considerations").
1059
1060 The receiving system MUST return a "successful" response from its
1061 HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. Other
1062 codes could indicate a delivery failure and may be retried as per
1063
1064
1065
1066Margolis, et al. Standards Track [Page 19]
1067
1068RFC 8460 SMTP TLS Reporting September 2018
1069
1070
1071 local sender policy. The receiving system is not expected to process
1072 reports at receipt time and MAY store them for processing at a later
1073 time.
1074
10755.5. Delivery Retry
1076
1077 In the event of a delivery failure, regardless of the delivery ../tlsrptsend/send.go:595
1078 method, a sender SHOULD attempt redelivery for up to 24 hours after
1079 the initial attempt. As previously stated, the reports are optional,
1080 so while it is ideal to attempt redelivery, it is not required. If
1081 multiple retries are attempted, ideally they SHOULD be done with
1082 exponential backoff.
1083
10845.6. Metadata Variances
1085
1086 As stated above, there are a variable number of ways to declare
1087 information about the data therein. If any of the items declared via
1088 subject or filename disagree with the report, the report MUST be
1089 considered the authoritative source.
1090
10916. IANA Considerations
1092
1093 The following are the IANA considerations discussed in this document.
1094
10956.1. Message Headers
1096
1097 Below is the Internet Assigned Numbers Authority (IANA) Permanent
1098 Message Header Field registration information per [RFC3864].
1099
1100 Header field name: TLS-Report-Domain
1101 Applicable protocol: mail
1102 Status: standard
1103 Author/Change controller: IETF
1104 Specification document(s): RFC 8460
1105
1106
1107 Header field name: TLS-Report-Submitter
1108 Applicable protocol: mail
1109 Status: standard
1110 Author/Change controller: IETF
1111 Specification document(s): RFC 8460
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122Margolis, et al. Standards Track [Page 20]
1123
1124RFC 8460 SMTP TLS Reporting September 2018
1125
1126
11276.2. Report Type
1128
1129 This document creates a new registry for the "report-type" parameter
1130 to the Content-Type header field for the "multipart/report" top-level
1131 media type defined in [RFC6522].
1132
1133 The registry name is "Report Type Registry", and the procedure for
1134 updating the registry will be "Specification Required" [RFC8126].
1135
1136 An entry in this registry should contain:
1137
1138 o the report-type being registered
1139
1140 o one or more registered media types that can be used with this
1141 report-type
1142
1143 o the document containing the registration action
1144
1145 o an optional comment
1146
1147 The initial entries are:
1148
1149 Report-Type: tlsrpt
1150 Media Type: application/tlsrpt+gzip, application/tlsrpt+json
1151 Registered By: [RFC8460]
1152 Comment: Media types suitable for use with this report-type are
1153 defined in Sections 6.4 and 6.5 of [RFC8460]
1154
1155 Report-Type: disposition-notification
1156 Media Type: message/disposition-notification
1157 Registered By: [RFC8098], Section 10
1158
1159 Report-Type: disposition-notification
1160 Media Type: message/global-disposition-notification
1161 Registered By: [RFC6533], Section 6
1162
1163 Report-Type: delivery-status
1164 Media Type: message/delivery-status
1165 Registered By: [RFC3464], Section 6.2
1166
1167 Report-Type: delivery-status
1168 Media Type: message/global-delivery-status
1169 Registered By: [RFC6533], Section 6
1170
1171
1172
1173
1174
1175
1176
1177
1178Margolis, et al. Standards Track [Page 21]
1179
1180RFC 8460 SMTP TLS Reporting September 2018
1181
1182
11836.3. +gzip Media Type Suffix
1184
1185 This document registers a new media type suffix "+gzip". The gzip
1186 format is a public domain, cross-platform, interoperable file storage
1187 and transfer format, specified in [RFC1952]; it supports compression
1188 and is used as the underlying representation by a variety of file
1189 formats. The media type "application/gzip" has been registered for
1190 such files. The suffix "+gzip" MAY be used with any media type whose
1191 representation follows that established for "application/gzip". The
1192 registration form for the structured syntax suffix for use with media
1193 types is as follows:
1194
1195 Type name: gzip file storage and transfer format.
1196
1197 +suffix: +gzip
1198
1199 References: [RFC1952] [RFC6713]
1200
1201 Encoding considerations: gzip is a binary encoding.
1202
1203 Fragment identifier considerations: The syntax and semantics of
1204 fragment identifiers specified for +gzip SHOULD be as specified for
1205 "application/gzip". (At publication of this document, there is no
1206 fragment identification syntax defined for "application/gzip".) The
1207 syntax and semantics for fragment identifiers for a specific "xxx/
1208 yyy+gzip" SHOULD be processed as follows:
1209
1210 For cases defined in +gzip, where the fragment identifier
1211 resolves per the +gzip rules, process as specified in
1212 +gzip.
1213
1214 For cases defined in +gzip, where the fragment identifier does
1215 not resolve per the +gzip rules, process as specified in
1216 "xxx/yyy+gzip".
1217
1218 For cases not defined in +gzip, process as specified in
1219 "xxx/yyy+gzip".
1220
1221 Interoperability considerations: N/A
1222
1223 Security considerations: gzip format doesn't provide confidentiality
1224 protection. Integrity protection is provided by an Adler-32
1225 checksum, which is not cryptographically strong. See also the
1226 security considerations of [RFC6713]. Each individual media type
1227 registered with a +gzip suffix can have additional security
1228 considerations. Additionally, gzip objects can contain multiple
1229
1230
1231
1232
1233
1234Margolis, et al. Standards Track [Page 22]
1235
1236RFC 8460 SMTP TLS Reporting September 2018
1237
1238
1239 files and associated paths. File paths must be validated when the
1240 files are extracted; a malicious file path could otherwise cause the
1241 extractor to overwrite application or system files.
1242
1243 Contact: art@ietf.org
1244
1245 Author/Change controller: Internet Engineering Task Force
1246 (iesg@ietf.org).
1247
12486.4. application/tlsrpt+json Media Type
1249
1250 This document registers multiple media types, beginning with Table 1
1251 below.
1252
1253 +-------------+----------------+-------------+-------------------+
1254 | Type | Subtype | File Ext | Specification |
1255 +-------------+----------------+-------------+-------------------+
1256 | application | tlsrpt+json | .json | Section 5.3 |
1257 +-------------+----------------+-------------+-------------------+
1258
1259 Table 1: SMTP TLS Reporting Media Type
1260
1261 Type name: application
1262
1263 Subtype name: tlsrpt+json
1264
1265 Required parameters: N/A
1266
1267 Optional parameters: N/A
1268
1269 Encoding considerations: Encoding considerations are identical to
1270 those specified for the "application/json" media type. See
1271 [RFC7493].
1272
1273 Security considerations: Security considerations relating to SMTP TLS
1274 Reporting are discussed in Section 7.
1275
1276 Interoperability considerations: This document specifies the format
1277 of conforming messages and the interpretation thereof.
1278
1279 Published specification: Section 5.3 of RFC 8460.
1280
1281 Applications that use this media type: Mail User Agents (MUAs) and
1282 Mail Transfer Agents.
1283
1284
1285
1286
1287
1288
1289
1290Margolis, et al. Standards Track [Page 23]
1291
1292RFC 8460 SMTP TLS Reporting September 2018
1293
1294
1295 Additional information:
1296
1297 Deprecated alias names for this type: N/A
1298
1299 Magic number(s): N/A
1300
1301 File extension(s): ".json"
1302
1303 Macintosh file type code(s): N/A
1304
1305 Person & email address to contact for further information:
1306 See the Authors' Addresses section.
1307
1308 Intended usage: COMMON
1309
1310 Restrictions on usage: N/A
1311
1312 Author: See the Authors' Addresses section.
1313
1314 Change controller: Internet Engineering Task Force (iesg@ietf.org).
1315
13166.5. application/tlsrpt+gzip Media Type
1317
1318 +-------------+----------------+-------------+-------------------+
1319 | Type | Subtype | File Ext | Specification |
1320 +-------------+----------------+-------------+-------------------+
1321 | application | tlsrpt+gzip | .gz | Section 5.3 |
1322 +-------------+----------------+-------------+-------------------+
1323
1324 Table 2: SMTP TLS Reporting Media Type
1325
1326 Type name: application
1327
1328 Subtype name: tlsrpt+gzip
1329
1330 Required parameters: N/A
1331
1332 Optional parameters: N/A
1333
1334 Encoding considerations: Binary
1335
1336 Security considerations: Security considerations relating to SMTP TLS
1337 Reporting are discussed in Section 7. Security considerations
1338 related to gzip compression are discussed in RFC 6713.
1339
1340 Interoperability considerations: This document specifies the format
1341 of conforming messages and the interpretation thereof.
1342
1343
1344
1345
1346Margolis, et al. Standards Track [Page 24]
1347
1348RFC 8460 SMTP TLS Reporting September 2018
1349
1350
1351 Published specification: Section 5.3 of RFC 8460.
1352
1353 Applications that use this media type: Mail User Agents (MUAs) and
1354 Mail Transfer Agents.
1355
1356 Additional information:
1357
1358 Deprecated alias names for this type: N/A
1359
1360 Magic number(s): The first two bytes are 0x1f, 0x8b.
1361
1362 File extension(s): ".gz"
1363
1364 Macintosh file type code(s): N/A
1365
1366 Person & email address to contact for further information:
1367 See the Authors' Addresses section.
1368
1369 Intended usage: COMMON
1370
1371 Restrictions on usage: N/A
1372
1373 Author: See the Authors' Addresses section.
1374
1375 Change controller: Internet Engineering Task Force (iesg@ietf.org).
1376
13776.6. STARTTLS Validation Result Types ../tlsrpt/report.go:281
1378
1379 This document creates a new registry, "STARTTLS Validation Result
1380 Types". The initial entries in the registry are:
1381
1382 +-----------------------------+--------------+
1383 | Result Type | Description |
1384 +-----------------------------+--------------+
1385 | starttls-not-supported | Section 4.3 |
1386 | certificate-host-mismatch | Section 4.3 |
1387 | certificate-expired | Section 4.3 |
1388 | tlsa-invalid | Section 4.3 |
1389 | dnssec-invalid | Section 4.3 |
1390 | dane-required | Section 4.3 |
1391 | certificate-not-trusted | Section 4.3 |
1392 | sts-policy-invalid | Section 4.3 |
1393 | sts-webpki-invalid | Section 4.3 |
1394 | validation-failure | Section 4.3 |
1395 | sts-policy-fetch-error | Section 4.3 |
1396 +-----------------------------+--------------+
1397
1398
1399
1400
1401
1402Margolis, et al. Standards Track [Page 25]
1403
1404RFC 8460 SMTP TLS Reporting September 2018
1405
1406
1407 The above entries are described in Section 4.3, "Result Types". New
1408 result types can be added to this registry using the "Expert Review"
1409 IANA registration policy.
1410
14117. Security Considerations
1412
1413 SMTP TLS Reporting provides visibility into misconfigurations or
1414 attempts to intercept or tamper with mail between hosts who support
1415 STARTTLS. There are several security risks presented by the
1416 existence of this reporting channel:
1417
1418 o Flooding of the Aggregate Report URI (rua) endpoint: An attacker
1419 could flood the endpoint with excessive reporting traffic and
1420 prevent the receiving domain from accepting additional reports.
1421 This type of Denial-of-Service attack would limit visibility into
1422 STARTTLS failures, leaving the receiving domain blind to an
1423 ongoing attack.
1424
1425 o Untrusted content: An attacker could inject malicious code into
1426 the report, exploiting any vulnerabilities in the report-handling
1427 systems of the receiving domain. Implementers are advised to take
1428 precautions against evaluating the contents of the report.
1429
1430 o Report snooping: An attacker could create a bogus TLSRPT record to
1431 receive statistics about a domain the attacker does not own.
1432 Since an attacker that is able to poison DNS is already able to
1433 receive counts of SMTP connections (and, absent DANE or MTA-STS
1434 policies, actual SMTP message payloads), this does not present a
1435 significant new vulnerability.
1436
1437 o Ignoring HTTPS validation when submitting reports: When reporting
1438 benign misconfigurations, it is likely that a misconfigured SMTP
1439 server may also mean a misconfigured HTTPS server; as a result,
1440 reporters who require HTTPS validity on the reporting endpoint may
1441 fail to alert administrators about such misconfigurations.
1442 Conversely, in the event of an actual attack, an attacker who
1443 wishes to create a gap in reporting and could intercept HTTPS
1444 reports could, just as easily, simply thwart the resolution of the
1445 TLSRPT TXT record or establishment of the TCP session to the HTTPS
1446 endpoint. Furthermore, such a man-in-the-middle attacker could
1447 discover most or all of the metadata exposed in a report merely
1448 through passive observation. As a result, we consider the risks
1449 of failure to deliver reports on misconfigurations to outweigh
1450 those of attackers intercepting reports.
1451
1452
1453
1454
1455
1456
1457
1458Margolis, et al. Standards Track [Page 26]
1459
1460RFC 8460 SMTP TLS Reporting September 2018
1461
1462
1463 o Reports as DDoS: TLSRPT allows specifying destinations for the ../webadmin/admin.go:1201
1464 reports that are outside the authority of the Policy Domain, which
1465 allows domains to delegate processing of reports to a partner
1466 organization. However, an attacker who controls the Policy Domain
1467 DNS could also use this mechanism to direct the reports to an
1468 unwitting victim, flooding that victim with excessive reports.
1469 DMARC [RFC7489] defines a solution for verifying delegation to
1470 avoid such attacks; the need for this is greater with DMARC,
1471 however, because DMARC allows an attacker to trigger reports to a
1472 target from an innocent third party by sending mail to that third
1473 party (which triggers a report from the third party to the
1474 target). In the case of TLSRPT, the attacker would have to induce
1475 the third party to send mail to the attacker in order to trigger
1476 reports from the third party to the victim; this reduces the risk
1477 of such an attack and the need for a verification mechanism.
1478
1479 Finally, because TLSRPT is intended to help administrators discover
1480 man-in-the-middle attacks against transport-layer encryption,
1481 including attacks designed to thwart negotiation of encrypted
1482 connections (by downgrading opportunistic encryption or, in the case
1483 of MTA-STS, preventing discovery of a new MTA-STS Policy), we must
1484 also consider the risk that an adversary who can induce such a
1485 downgrade attack can also prevent discovery of the TLSRPT TXT record
1486 (and thus prevent discovery of the successful downgrade attack).
1487 Administrators are thus encouraged to deploy TLSRPT TXT records with
1488 a large TTL (reducing the window for successful application of
1489 transient attacks against DNS resolution of the record) or to deploy
1490 DNSSEC on the deploying zone.
1491
14928. Privacy Considerations
1493
1494 MTAs are generally considered public knowledge; however, the
1495 internals of how those MTAs are configured and the users of those
1496 MTAs may not be as public. It should be noted that providing a
1497 receiving site with information about TLS failures may reveal
1498 information about the sender's configuration or even information
1499 about the senders themselves. For example, sending a report may
1500 disclose what TLS implementation the sender uses, as the inability to
1501 negotiate a session may be a known incompatibility between two
1502 implementations. This may, indirectly, leak information on the
1503 reporter's operating system or even region, if, for example, a rare
1504 TLS implementation is popular among certain users or in certain
1505 locations.
1506
1507
1508
1509
1510
1511
1512
1513
1514Margolis, et al. Standards Track [Page 27]
1515
1516RFC 8460 SMTP TLS Reporting September 2018
1517
1518
15199. References
1520
15219.1. Normative References
1522
1523 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
1524 RFC 1952, DOI 10.17487/RFC1952, May 1996,
1525 <https://www.rfc-editor.org/info/rfc1952>.
1526
1527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1528 Requirement Levels", BCP 14, RFC 2119,
1529 DOI 10.17487/RFC2119, March 1997,
1530 <https://www.rfc-editor.org/info/rfc2119>.
1531
1532 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
1533 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
1534 <https://www.rfc-editor.org/info/rfc3339>.
1535
1536 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1537 for Internationalized Domain Names in Applications
1538 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
1539 <https://www.rfc-editor.org/info/rfc3492>.
1540
1541 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1542 Resource Identifier (URI): Generic Syntax", STD 66,
1543 RFC 3986, DOI 10.17487/RFC3986, January 2005,
1544 <https://www.rfc-editor.org/info/rfc3986>.
1545
1546 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1547 Specifications: ABNF", STD 68, RFC 5234,
1548 DOI 10.17487/RFC5234, January 2008,
1549 <https://www.rfc-editor.org/info/rfc5234>.
1550
1551 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1552 Housley, R., and W. Polk, "Internet X.509 Public Key
1553 Infrastructure Certificate and Certificate Revocation List
1554 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1555 <https://www.rfc-editor.org/info/rfc5280>.
1556
1557 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1558 DOI 10.17487/RFC5321, October 2008,
1559 <https://www.rfc-editor.org/info/rfc5321>.
1560
1561 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1562 DOI 10.17487/RFC5322, October 2008,
1563 <https://www.rfc-editor.org/info/rfc5322>.
1564
1565
1566
1567
1568
1569
1570Margolis, et al. Standards Track [Page 28]
1571
1572RFC 8460 SMTP TLS Reporting September 2018
1573
1574
1575 [RFC5891] Klensin, J., "Internationalized Domain Names in
1576 Applications (IDNA): Protocol", RFC 5891,
1577 DOI 10.17487/RFC5891, August 2010,
1578 <https://www.rfc-editor.org/info/rfc5891>.
1579
1580 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
1581 Address Text Representation", RFC 5952,
1582 DOI 10.17487/RFC5952, August 2010,
1583 <https://www.rfc-editor.org/info/rfc5952>.
1584
1585 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
1586 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
1587 <https://www.rfc-editor.org/info/rfc6068>.
1588
1589 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1590 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1591 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1592 <https://www.rfc-editor.org/info/rfc6376>.
1593
1594 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
1595 the Reporting of Mail System Administrative Messages",
1596 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
1597 <https://www.rfc-editor.org/info/rfc6522>.
1598
1599 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1600 of Named Entities (DANE) Transport Layer Security (TLS)
1601 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
1602 2012, <https://www.rfc-editor.org/info/rfc6698>.
1603
1604 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip'
1605 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012,
1606 <https://www.rfc-editor.org/info/rfc6713>.
1607
1608 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1609 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1610 DOI 10.17487/RFC7208, April 2014,
1611 <https://www.rfc-editor.org/info/rfc7208>.
1612
1613 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1614 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
1615 DOI 10.17487/RFC7231, June 2014,
1616 <https://www.rfc-editor.org/info/rfc7231>.
1617
1618 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1619 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1620 <https://www.rfc-editor.org/info/rfc7405>.
1621
1622
1623
1624
1625
1626Margolis, et al. Standards Track [Page 29]
1627
1628RFC 8460 SMTP TLS Reporting September 2018
1629
1630
1631 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
1632 DOI 10.17487/RFC7493, March 2015,
1633 <https://www.rfc-editor.org/info/rfc7493>.
1634
1635 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
1636 Authentication of Named Entities (DANE) Protocol: Updates
1637 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
1638 October 2015, <https://www.rfc-editor.org/info/rfc7671>.
1639
1640 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1641 Opportunistic DNS-Based Authentication of Named Entities
1642 (DANE) Transport Layer Security (TLS)", RFC 7672,
1643 DOI 10.17487/RFC7672, October 2015,
1644 <https://www.rfc-editor.org/info/rfc7672>.
1645
1646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1648 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1649
1650 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
1651 and J. Jones, "SMTP MTA Strict Transport Security (MTA-
1652 STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
1653 <https://www.rfc-editor.org/info/rfc8461>.
1654
16559.2. Informative References
1656
1657 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1658 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
1659 February 2002, <https://www.rfc-editor.org/info/rfc3207>.
1660
1661 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1662 for Delivery Status Notifications", RFC 3464,
1663 DOI 10.17487/RFC3464, January 2003,
1664 <https://www.rfc-editor.org/info/rfc3464>.
1665
1666 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1667 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
1668 <https://www.rfc-editor.org/info/rfc3501>.
1669
1670 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
1671 Procedures for Message Header Fields", BCP 90, RFC 3864,
1672 DOI 10.17487/RFC3864, September 2004,
1673 <https://www.rfc-editor.org/info/rfc3864>.
1674
1675 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov,
1676 "Internationalized Delivery Status and Disposition
1677 Notifications", RFC 6533, DOI 10.17487/RFC6533, February
1678 2012, <https://www.rfc-editor.org/info/rfc6533>.
1679
1680
1681
1682Margolis, et al. Standards Track [Page 30]
1683
1684RFC 8460 SMTP TLS Reporting September 2018
1685
1686
1687 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1688 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1689 December 2014, <https://www.rfc-editor.org/info/rfc7435>.
1690
1691 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
1692 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
1693 2015, <https://www.rfc-editor.org/info/rfc7469>.
1694
1695 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1696 Message Authentication, Reporting, and Conformance
1697 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1698 <https://www.rfc-editor.org/info/rfc7489>.
1699
1700 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
1701 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
1702 February 2017, <https://www.rfc-editor.org/info/rfc8098>.
1703
1704 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1705 Writing an IANA Considerations Section in RFCs", BCP 26,
1706 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1707 <https://www.rfc-editor.org/info/rfc8126>.
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738Margolis, et al. Standards Track [Page 31]
1739
1740RFC 8460 SMTP TLS Reporting September 2018
1741
1742
1743Appendix A. Example Reporting Policy
1744
1745A.1. Report Using MAILTO
1746
1747 _smtp._tls.mail.example.com. IN TXT \
1748 "v=TLSRPTv1;rua=mailto:reports@example.com"
1749
1750A.2. Report Using HTTPS
1751
1752 _smtp._tls.mail.example.com. IN TXT \
1753 "v=TLSRPTv1; \
1754 rua=https://reporting.example.com/v1/tlsrpt"
1755
1756Appendix B. Example JSON Report ../tlsrpt/report_test.go:116
1757
1758 Below is an example JSON report for messages from Company-X to
1759 Company-Y, where 100 sessions were attempted to Company-Y servers
1760 with an expired certificate, and 200 sessions were attempted to
1761 Company-Y servers that did not successfully respond to the "STARTTLS"
1762 command. Additionally, 3 sessions failed due to
1763 "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
1764
1765 {
1766 "organization-name": "Company-X",
1767 "date-range": {
1768 "start-datetime": "2016-04-01T00:00:00Z",
1769 "end-datetime": "2016-04-01T23:59:59Z" ../tlsrptsend/send.go:412
1770 },
1771 "contact-info": "sts-reporting@company-x.example",
1772 "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", 8460:968 8460:691 todo spec: ../tlsrptsend/send.go:415
1773 "policies": [{
1774 "policy": {
1775 "policy-type": "sts",
1776 "policy-string": ["version: STSv1","mode: testing",
1777 "mx: *.mail.company-y.example","max_age: 86400"],
1778 "policy-domain": "company-y.example",
1779 "mx-host": "*.mail.company-y.example" 8460-eid6241:1 ../tlsrpt/report.go:245
1780 },
1781 "summary": {
1782 "total-successful-session-count": 5326,
1783 "total-failure-session-count": 303
1784 },
1785 "failure-details": [{
1786 "result-type": "certificate-expired",
1787 "sending-mta-ip": "2001:db8:abcd:0012::1",
1788 "receiving-mx-hostname": "mx1.mail.company-y.example",
1789 "failed-session-count": 100
1790 }, {
1791
1792
1793
1794Margolis, et al. Standards Track [Page 32]
1795
1796RFC 8460 SMTP TLS Reporting September 2018
1797
1798
1799 "result-type": "starttls-not-supported",
1800 "sending-mta-ip": "2001:db8:abcd:0013::1",
1801 "receiving-mx-hostname": "mx2.mail.company-y.example",
1802 "receiving-ip": "203.0.113.56",
1803 "failed-session-count": 200,
1804 "additional-information": "https://reports.company-x.example/
1805 report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
1806 }, {
1807 "result-type": "validation-failure",
1808 "sending-mta-ip": "198.51.100.62",
1809 "receiving-ip": "203.0.113.58",
1810 "receiving-mx-hostname": "mx-backup.mail.company-y.example",
1811 "failed-session-count": 3,
1812 "failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
1813 }]
1814 }]
1815 }
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850Margolis, et al. Standards Track [Page 33]
1851
1852RFC 8460 SMTP TLS Reporting September 2018
1853
1854
1855Contributors
1856
1857 Laetitia Baudoin
1858 Google, Inc.
1859 lbaudoin@google.com
1860
1861Authors' Addresses
1862
1863 Daniel Margolis
1864 Google, Inc.
1865
1866 Email: dmargolis@google.com
1867
1868
1869 Alexander Brotman
1870 Comcast, Inc.
1871
1872 Email: alex_brotman@comcast.com
1873
1874
1875 Binu Ramakrishnan
1876 Oath, Inc.
1877
1878 Email: prbinu@yahoo.com
1879
1880
1881 Janet Jones
1882 Microsoft, Inc.
1883
1884 Email: janet.jones@microsoft.com
1885
1886
1887 Mark Risher
1888 Google, Inc.
1889
1890 Email: risher@google.com
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906Margolis, et al. Standards Track [Page 34]
1907
1908