DMARC Failure reporting Interval tag
draft-davids-dmarc-fi-tag-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Marco Davids | ||
| Last updated | 2016-10-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davids-dmarc-fi-tag-00
DMARC Working Group M. Davids
Internet-Draft SIDN Labs
Updates: 7489 (if approved) October 27, 2016
Intended status: Standards Track
Expires: April 30, 2017
DMARC Failure reporting Interval tag
draft-davids-dmarc-fi-tag-00
Abstract
This document extends the DMARC (RFC7489) record format by defining
an additional tag. This new tag, the "fi" tag, is to be used in
conjunction with the "ruf" tag. It enables a simple way of rate
limiting the message-specific failure reporting on the request of a
Domain Owner.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Davids Expires April 30, 2017 [Page 1]
Internet-Draft DMARC-fi October 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Extension to the General Record Format . . . . . . . . . . . 3
4. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 3
5. Domain Owner Example . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . 6
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Domain Owners may have various reasons to permanently configure a
"ruf" tag. For example in the case of reputation management,
monitoring or research this can be seen as useful functionality.
DMARC [RFC7489] per-message failure reports ("ruf") are sent almost
immediately and in a non-aggregated manner. Under certain
circumstances this can potentially lead to an undesirable high volume
of reports. Especially in the case where the Domain Owner's name is
spoofed and abused in a large scale phishing or other impersonation
attack.
DMARC [RFC7489] Section 7.3 leaves it to the discretion of
participating Mail Receivers and report generators to take measures
against sending high volumes of failure reports. But their mileage
may vary and the measures they take, if any, may not meet the
criteria of the Domain Owner at the receiving end.
The lack of a mechanism to influence the volume of reports from a
Domain Owners' perspective, constitutes an obstacle for deployment of
this feature.
This document updates [RFC7489] by defining the "fi" tag, a mechanism
that allows the Domain Owner to request a limitation of no more than
one failure report per report generator per time interval.
Davids Expires April 30, 2017 [Page 2]
Internet-Draft DMARC-fi October 2016
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
The following terms are also used, as defined in DMARC [RFC7489].
Domain Owner and Mail Receiver.
3. Extension to the General Record Format
The following tag is introduced as an additional valid DMARC tag for
use in conjunction with the Reporting URI for Failure ("ruf") tag:
fi: Interval requested between message-specific failure reports
(plain-text 32-bit unsigned integer; OPTIONAL; if not defined or 0,
then there is no rate limiting requested). Indicates a request to
report generators to send per-message failure reports with an
interval of approximately the requested number in seconds. But no
more than that.
Any intermediate remaining reports SHOULD NOT be sent and MAY be
disgarded if generated at all. But disregarding per-message failure
reports as a consequence of this tag, SHALL NOT affect the
statistical information in aggregated feedback repports.
Report generators that choose to adhere to the "ruf" tag option,
SHOULD also adhere to the requested "fi" tag setting defined here.
This tag's content SHALL be ignored if a "ruf" tag is not also
specified, or if the syntax of the integer is invalid.
Report generators that implement this feature MUST be able to support
the entire interval range from 0-86400 and MAY support longer
intervals.
4. Formal Definition
The formal definition of the "fi" tag format, using ABNF [RFC5234],
is as follows:
Introduced:
dmarc-finterval = "fi" \*WSP "=" \*WSP 1\*DIGIT
Updated:
Davids Expires April 30, 2017 [Page 3]
Internet-Draft DMARC-fi October 2016
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-finterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
5. Domain Owner Example
The DMARC policy record with the "fi" tag might look like this when
retrieved using a common command-line tool:
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@example.com; fi=300;"
To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com; fi=300; " )
The request implicates that the Domain Owner is willing to accept no
more than one per-message failure report every 5 minutes from any
report generator.
6. IANA Considerations
As per [RFC7489 p.17] Section 6.3 last paragraph, a new version of
DMARC is not required. Older implementations that consider the "fi"
tag as unknown, will ignore it.
However, this document requires an update of the IANA [RFC5226] DMARC
Tag Registry [1]:
Davids Expires April 30, 2017 [Page 4]
Internet-Draft DMARC-fi October 2016
Tag Name | Description
---------+---------------------------
fi | Failure Reporting interval
7. Security Considerations
The Domain Owner should be aware that defining a "fi" tag is a trade-
off between too much reports and possibly missing out on some
details. A large scale attack that triggers the rate limiting, might
block the generation of reports for other events on the same domain
to the same Mail Receiver.
An attack could involve many different report generators. The Domain
Owner should be aware that the "fi" tag is on a per report generator
basis. Combined, multiple report generators might still generate a
considerable amount of reports. An attack could also involve
multiple domains of one particular Domain Owner. The "fi" tag is on
a per domain basis, so a deliberate abuse of multiple spoofed domains
of one Domain Owner, might still generate high volumes of per-message
failure reports.
Therefore it makes sense to define a relatively short TTL on DMARC-
records, to allow for the possibility of increasing the "fi"-value on
an ad hoc basis, or to remove the "ruf" (and "fi") tag altogether in
case of a problem.
The security of the DMARC TXT-record of which the "fi" tag is a part,
rests on the security of the underlying DNS infrastructure. In that
respect is is advisable to make use of DNSSEC.
8. Discussion
The DMARC virtual verification draft [draft-akagiri-dmarc-virtual-
verification] discusses possible values for the "ruf" tag. The
authors of that draft are kindly requested to take this draft into
consideration as part of their discussions.
9. Acknowledgments
TBD
10. References
10.1. Normative References
Davids Expires April 30, 2017 [Page 5]
Internet-Draft DMARC-fi October 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
10.2. Informative References
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
10.3. URIs
[1] https://www.iana.org/assignments/dmarc-parameters/dmarc-
parameters.xhtml
Author's Address
Marco Davids
SIDN
Meander 501
Arnhem 6825 MD
NL
Phone: +31 26 352 5500
Email: marco.davids@sidn.nl
Davids Expires April 30, 2017 [Page 6]