idnits 2.17.1 draft-davids-dmarc-fi-tag-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7489, but the abstract doesn't seem to directly say this. It does mention RFC7489 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2016) is 2707 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 312 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group M. Davids 3 Internet-Draft SIDN Labs 4 Updates: 7489 (if approved) November 24, 2016 5 Intended status: Standards Track 6 Expires: May 28, 2017 8 DMARC Failure reporting Interval tag 9 draft-davids-dmarc-fi-tag-01 11 Abstract 13 This document extends the DMARC (RFC7489) record format by defining 14 an additional tag. This new tag, the "fi" tag, is to be used in 15 conjunction with the "ruf" tag used for message-specific failure 16 reporting. It provides a Domain Owner with a simple way of 17 requesting limitation of the rate at which such reports are sent. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 28, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 55 3. Extension to the General Record Format . . . . . . . . . . . 3 56 4. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Domain Owner Example . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 10.2. Informative References . . . . . . . . . . . . . . . . . 7 65 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 DMARC [RFC7489] enables Domain Owners to request for detailed failure 71 reports for individual messages by means of the "ruf" tag. There may 72 be various reasons to permanently configure such a "ruf" tag. For 73 example to facilitate reputation management, monitoring or simply for 74 research or operational purposes. 76 Failure reports are normally generated and sent almost immediately 77 after the Mail Receiver detects a DMARC failure. These reports are 78 useful for quickly notifying the Domain Owners of an authentication 79 failure, without waiting for an aggregate report. However, under 80 certain circumstances this property can potentially lead to an 81 undesirably high volume of reports. Especially when a Domain Owner's 82 name is spoofed and abused in a large-scale phishing or other 83 impersonation attack. 85 DMARC [RFC7489] Section 7.3 leaves it to the discretion of 86 participating Mail Receivers and report generators if and how they 87 take measures against sending high volumes of failure reports. 88 However, what a Mail Receiver or report generator considers 89 acceptable may exceed the capacity of the receiving Domain Owner. 90 The lack of a mechanism for a Domain Owner to influence the volume of 91 reports constitutes an obstacle to deployment of the "ruf" tag 92 feature. 94 This document updates [RFC7489] by defining the "fi" tag, a mechanism 95 that allows the Domain Owner to request the limitation of failure 96 reports of no more than one failure report per report generator per 97 time interval. 99 2. Conventions Used In This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] when they 104 appear in ALL CAPS. These words may also appear in this document in 105 lower case as plain English words, absent their normative meanings. 107 The following terms are used, as defined in DMARC [RFC7489]. 109 Domain Owner and Mail Receiver. 111 Also the term "report generator" is applied here the same way as in 112 DMARC [RFC7489]. 114 3. Extension to the General Record Format 116 The following tag is introduced as an additional valid DMARC tag for 117 use in conjunction with the Reporting URI for Failure ("ruf") tag: 119 fi: 120 Interval requested between message-specific failure reports 121 (plain-text 32-bit unsigned integer; OPTIONAL; if not defined or 122 0, then there is no rate limitation requested). Indicates a 123 request to report generators to send message-specific failure 124 reports at an interval of approximately the requested number of 125 seconds. 127 Any intermediate remaining reports SHOULD NOT be sent and MAY be 128 discarded, if generated at all. But discarding message-specific 129 failure reports as a consequence of this tag, SHALL NOT affect the 130 completeness of information in the aggregated feedback reports. 132 A report generator MAY include in the message-specific failure report 133 an indication of the number of reports discarde since the last issued 134 report. Where AFRF [RFC6591] is used, the Abuse Reporting Format 135 [RFC5965] optional "Incidents"-field may be used to indicate the 136 number of discarded reports. 138 Report generators that choose to adhere to the "ruf" tag option, 139 SHOULD also adhere to the requested "fi" tag setting defined here. 140 This tag's content SHALL be ignored if a "ruf" tag is not also 141 specified, or if the syntax of the "fi" integer is invalid. 143 Report generators that implement this feature MUST be able to support 144 the entire interval range from 0-86400 and MAY support longer 145 intervals. 147 4. Formal Definition 149 The formal definition of the "fi" tag format, using ABNF [RFC5234], 150 is as follows: 152 Introduced: 154 dmarc-finterval = "fi" *WSP "=" *WSP 1*DIGIT 156 Which changes the dmarc-record definition to: 158 dmarc-record = dmarc-version dmarc-sep 159 [dmarc-request] 160 [dmarc-sep dmarc-srequest] 161 [dmarc-sep dmarc-auri] 162 [dmarc-sep dmarc-furi] 163 [dmarc-sep dmarc-adkim] 164 [dmarc-sep dmarc-aspf] 165 [dmarc-sep dmarc-ainterval] 166 [dmarc-sep dmarc-finterval] 167 [dmarc-sep dmarc-fo] 168 [dmarc-sep dmarc-rfmt] 169 [dmarc-sep dmarc-percent] 170 [dmarc-sep] 171 ; components other than dmarc-version and 172 ; dmarc-request may appear in any order 174 5. Domain Owner Example 176 The DMARC policy record with the "fi" tag might look like this when 177 retrieved using a common command-line tool: 179 % dig +short TXT _dmarc.example.com. 180 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 181 ruf=mailto:auth-reports@example.com; fi=300;" 183 To publish such a record, the DNS administrator for the Domain Owner 184 might create an entry like the following in the appropriate zone file 185 (following the conventional zone file format): 187 ; DMARC record for the domain example.com 189 _dmarc IN TXT ( "v=DMARC1; p=none; " 190 "rua=mailto:dmarc-feedback@example.com; " 191 "ruf=mailto:auth-reports@example.com; fi=300; " ) 193 The request implies that the Domain Owner is willing to accept no 194 more than one message-specific failure report every 5 minutes from 195 any report generator. A report generator in this example would 196 typically honour the "fi" tag by sending out a report, storing a 197 'last report sent' timestamp for example.com in memory and 198 maintaining it as a 'do not sent' flag for a minimum of 300 seconds 199 during which period no consecutive reports are to be sent. After the 200 flag has cleared, a report may again be sent. The cycle then 201 repeats. 203 Intermediate, unsent reports are discarded. But they do add to 204 statistical counters as if they were sent. So their details are part 205 of any corresponding aggregated reports. 207 Any optionally defined indications for the maximum report size in the 208 URI will continue to work as defined in [RFC7489]. 210 6. IANA Considerations 212 As per [RFC7489 p.17] Section 6.3 last paragraph, a new version of 213 DMARC is not required. Older implementations that consider the "fi" 214 tag as unknown, will ignore it. 216 However, this document requires an update to the IANA [RFC5226] DMARC 217 Tag Registry [1]: 219 Tag Name | Description 220 ---------+--------------------------- 221 fi | Failure Reporting interval 223 7. Security Considerations 225 The Domain Owner should be aware that defining a "fi" tag involves a 226 trade-off between the benefit of preventing unmanageable incoming 227 report flows and the risk of not receiving potentially useful data. 228 A large scale attack that triggers reporting rate limitation, might 229 result in the non-dispatch of reports regarding other events 230 involving the same domain to the same Mail Receiver. 232 An attack can involve many different report generators. The Domain 233 Owner should be aware that the "fi" tag limits reporting by each 234 individual report generator. Multiple report generators might still 235 collectively generate a large volume of reports. Mail Receivers with 236 a farm or cluster of several report generators might choose to 237 synchronise the 'last sent' timestamp value accross their machines in 238 order to better comply with the wishes of Domain Owners and to reduce 239 the risk described above. 241 An attack can also involve multiple domains belonging to a single 242 Domain Owner. The "fi" tag applies to an individual domain, so the 243 deliberate abuse of multiple spoofed domains belonging to Domain 244 Owner, might still generate a high volumes of message-specific 245 failure reports. 247 It therefore it makes sense to define a relatively short TTL for 248 DMARC-records, to allow for the possibility of increasing the "fi"- 249 value on an ad hoc basis, or to remove the "ruf" (and "fi") tag 250 altogether in the even of a problem. 252 [TODO: mention the part hereafter, or is it out of scope for this 253 draft?] An attacker that enforces message-specific detailed failure 254 ("ruf") reports that are larger than an optionally-defined maximum- 255 size specification, may leave the Domain Owner in the darks, because 256 no reports will be sent. 258 The security of the DMARC TXT-record, which the "fi" tag part of, 259 depends on the security of the underlying DNS infrastructure. In 260 that respect it is advisable to make use of DNSSEC. 262 8. Discussion 264 The DMARC virtual verification draft [draft-akagiri-dmarc-virtual- 265 verification] discusses possible values for the "ruf" tag. The 266 authors of that draft are kindly requested to take this draft into 267 consideration as part of their discussions. 269 9. Acknowledgments 271 The author would like to thank Elizabeth Zwicky, Moritz Mueller, 272 Maarten Wullink, Cristian Hesselman and Bart Knubben for their 273 valuable feedback. 275 10. References 277 10.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 285 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 286 DOI 10.17487/RFC5226, May 2008, 287 . 289 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 290 Specifications: ABNF", STD 68, RFC 5234, 291 DOI 10.17487/RFC5234, January 2008, 292 . 294 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 295 Extensible Format for Email Feedback Reports", RFC 5965, 296 DOI 10.17487/RFC5965, August 2010, 297 . 299 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 300 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 301 April 2012, . 303 10.2. Informative References 305 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 306 Message Authentication, Reporting, and Conformance 307 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 308 . 310 10.3. URIs 312 [1] https://www.iana.org/assignments/dmarc-parameters/dmarc- 313 parameters.xhtml 315 Author's Address 317 Marco Davids 318 SIDN 319 Meander 501 320 Arnhem 6825 MD 321 NL 323 Phone: +31 26 352 5500 324 Email: marco.davids@sidn.nl