MARF Working Group M. Kucherawy Internet-Draft Cloudmark Intended status: Standards Track H. Fontana Expires: July 11, 2011 eCert Systems January 7, 2011 Authentication Failure Reporting using the Abuse Report Format draft-ietf-marf-dkim-reporting-01 Abstract This memo presents extensions to the Abuse Reporting Format (ARF), DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. 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 July 11, 2011. Copyright Notice Copyright (c) 2011 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kucherawy & Fontana Expires July 11, 2011 [Page 1] Internet-Draft Auth Failure Reporting January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Imported Definitions . . . . . . . . . . . . . . . . . . . 4 3. Optional Reporting Address for DKIM . . . . . . . . . . . . . 5 4. Optional Reporting Address for DKIM-ADSP . . . . . . . . . . . 7 5. Optional Reporting Address for SPF . . . . . . . . . . . . . . 9 6. Requested Reports . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Requested Reports for DKIM Failures . . . . . . . . . . . 11 6.2. Requested Reports for DKIM ADSP Failures . . . . . . . . . 11 6.3. Requested Reports for SPF Failures . . . . . . . . . . . . 11 7. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 12 8. Extension ARF Fields for Authentication Failure Reporting . . 13 8.1. New ARF Feedback Type . . . . . . . . . . . . . . . . . . 13 8.2. New ARF Header Field Names . . . . . . . . . . . . . . . . 14 8.2.1. Required For All Reports . . . . . . . . . . . . . . . 14 8.2.2. Required For DKIM Reports . . . . . . . . . . . . . . 14 8.2.3. Optional For DKIM Reports . . . . . . . . . . . . . . 15 8.2.4. Optional For SPF Reports . . . . . . . . . . . . . . . 15 8.3. Authentication Failure Types . . . . . . . . . . . . . . . 15 9. Syntax For Added Fields . . . . . . . . . . . . . . . . . . . 17 10. Redacting Data . . . . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11.1. DKIM Key Tag Registration . . . . . . . . . . . . . . . . 19 11.2. DKIM ADSP Tag Registration . . . . . . . . . . . . . . . . 19 11.3. SPF Tag Registration . . . . . . . . . . . . . . . . . . . 19 11.4. Updates to ARF Feedback Types . . . . . . . . . . . . . . 20 11.5. Updates to ARF Header Field Names . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12.1. Inherited Considerations . . . . . . . . . . . . . . . . . 23 12.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 23 12.3. Automatic Generation . . . . . . . . . . . . . . . . . . . 23 12.4. Envelope Sender Selection . . . . . . . . . . . . . . . . 24 12.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 B.1. Example Use of DKIM Key Extension Tags . . . . . . . . . . 27 B.2. Example Use of DKIM ADSP Extension Tags . . . . . . . . . 27 B.3. Example Use of ARF Extension Headers . . . . . . . . . . . 28 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Kucherawy & Fontana Expires July 11, 2011 [Page 2] Internet-Draft Auth Failure Reporting January 2011 1. Introduction [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye toward automating both the generating and consumption of those reports. [SPF] and [DKIM] introduced mechanisms for message sender authentication; the former is "path-based" meaning it authenticates the route that a message took from origin to destination, and the latter uses digital signing to associate a domain name with a message in a reliable (i.e. not forgeable) manner. In both cases the output is a verified domain name that can then be subjected to some sort of evaluation process (e.g., comparison to a known-good list, submission to a reputation service, etc.). Deployers of message sender authentication technologies are increasingly seeking visibility into DKIM verification failures, unauthorized path traversals (SPF failures), and conformance failures involving an ADMD's published signing practices ([ADSP]). This document extends [DKIM], [SPF] and [ADSP] to add an optional reporting address, an optional means of specifying a desired report format and other parameters, and furthermore extends [ARF] to add features required for the reporting of these incidents. Kucherawy & Fontana Expires July 11, 2011 [Page 3] Internet-Draft Auth Failure Reporting January 2011 2. Definitions 2.1. Keywords 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 [KEYWORDS]. 2.2. Imported Definitions The ABNF token "qp-section" is imported from [MIME]. base64 is defined in [MIME]. Kucherawy & Fontana Expires July 11, 2011 [Page 4] Internet-Draft Auth Failure Reporting January 2011 3. Optional Reporting Address for DKIM A domain name owner employing [DKIM] for e-mail signing and authentication might want to know when signatures in use by specific keys are not successfully verifying. Currently there is no such mechanism defined. This document adds the following optional "tags" (as defined in [DKIM]) to the DKIM key records, using the form defined in that specification: r= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing an e-mail address to which a report SHOULD be sent when mail signed with this key fails verification because either (a) the signature verification itself failed, or (b) the body hash test failed. The format of this reply is selected by the value of the "rf=" tag, defined below. If only a local-part is included, then to generate a complete address to which the report is sent, the verifier simply appends to this value an "@" followed by the domain found in the "d=" tag of the signature whose validation failed. ABNF: key-r-tag = %x72 *WSP "=" *WSP qp-section rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The value MUST be a colon-separated list of tokens representing desired reporting formats in order of preference. Each element of the list MUST be a token that is taken from the registered list of report formats. See Section 11 for a description of the registry and Section 7 for a description of recognized formats. The verifier generating reports MUST generate a report using the first token in the list that represents a report format it is capable of generating. ABNF: rep-format = ( "arf" / "smtp" ) key-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP rep-format ) ri= Requested Report Interval (plain-text; OPTIONAL; default is "0"). The value is an unsigned 32-bit integer that specifies an interval during which the report generator SHOULD NOT issue more than one report about a given incident type. A value of "0" requests a report for every incident. Where the requested Kucherawy & Fontana Expires July 11, 2011 [Page 5] Internet-Draft Auth Failure Reporting January 2011 interval is not zero, the agent generating a report SHOULD include an "Incidents:" field in the generated report so the receiving agent has some indication of how many reports were suppressed. ABNF: key-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT ro= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 6.1 for a list of valid tags. ABNF: key-ro-type = ( "all" / "s" / "v" / "x" ) key-ro-tag = %x72 %x6f *WSP "=" *WSP key-ro-type *WSP 0* ( ":" *WSP key-ro-type ) rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a string the signing domain requests be included in [SMTP] error strings when messages are rejected. ABNF: key-rs-tag = %x72 %x73 *WSP "=" qp-section Kucherawy & Fontana Expires July 11, 2011 [Page 6] Internet-Draft Auth Failure Reporting January 2011 4. Optional Reporting Address for DKIM-ADSP There also exist cases in which a domain name owner employing [ADSP] for announcing signing practises with DKIM may want to know when messages are received without valid author domain signatures. Currently there is no such mechanism defined. This document adds the following optional "tags" (as defined in [ADSP]) to the DKIM ADSP records, using the form defined in that specification: r= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing an e-mail address to which a report SHOULD be sent when mail claiming to be from this domain failed the verification algorithm described in [ADSP], in particular because a message arrived without a signature that validates, which contradicts what the ADSP record claims, the format of this reply MUST be in the format specified by the "rf=" tag defined below. If only a local-part is provided, then to generate a complete address to which the report is sent, the verifier simply appends to this value an "@" followed by the domain whose policy was queried in order to evaluate the sender's ADSP. ABNF: adsp-r-tag = %x72 *WSP "=" qp-section rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The value MUST be a colon-separated list of tokens representing desired reporting formats in decreasing order of preference. Each element of the list MUST be a token that is taken from the registered list of DKIM report formats. See Section 11 for a description of the registry and Section 7 for a description of recognized formats. The verifier generating reports MUST generate a report using the first token in the list that represents a report format it is capable of generating. ABNF: adsp-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP rep-format ) ri= Requested Report Interval (plain-text; OPTIONAL; default is "0"). The value is an unsigned 32-bit integer that specifies an interval during which the report generator SHOULD NOT issue more than one report about a given type of incident should be generated. A value of "0" requests a report for every incident. Kucherawy & Fontana Expires July 11, 2011 [Page 7] Internet-Draft Auth Failure Reporting January 2011 Where the requested interval is not zero, the agent generating a report SHOULD include an "Incidents:" field in the generated report so the receiving agent has some indication of how many reports were suppressed. ABNF: adsp-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT ro= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 6.2 for a list of valid tags. ABNF: adsp-ro-type = ( "all" / "s" / "u" ) adsp-ro-tag = %x72 %x6f *WSP "=" *WSP adsp-ro-type *WSP 0* ( ":" *WSP adsp-ro-type ) rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a string the signing domain requests be included in [SMTP] error strings when messages are rejected. ABNF: adsp-rs-tag = %x72 %x73 *WSP "=" qp-section Kucherawy & Fontana Expires July 11, 2011 [Page 8] Internet-Draft Auth Failure Reporting January 2011 5. Optional Reporting Address for SPF There also exist cases in which a domain name owner employing [SPF] for announcing sending practises may want to know when messages are received via unauthorized routing. Currently there is no such mechanism defined. This document adds the following optional "modifier" (as defined in Section 4.6.1 of [SPF]) to SPF records, using the form defined in that specification: report= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing an e-mail address to which a report SHOULD be sent when mail claiming to be from this domain failed the SPF evaluation algorithm described in [SPF], in particular because a message arrived via an unauthorized route. The format of this reply MUST be in the format specified by the "reportform=" tag defined below. If only a local-part is provided, then to generate a complete address to which the report is sent, the verifier simply appends to this value an "@" followed by the domain whose policy was queried in order to evaluate the sender's SPF record. ABNF: spf-report-tag = "report" *WSP "=" qp-section reportform= Reporting Format (plain-text; OPTIONAL; default is "arf"). The value MUST be a colon-separated list of tokens representing desired reporting formats in decreasing order of preference. Each element of the list MUST be a token that is taken from the registered list of report formats. See Section 11 for a description of the registry and Section 7 for a description of recognized formats. The verifier generating reports MUST generate a report using the first token in the list that represents a report format it is capable of generating. ABNF: spf-rf-tag = "reportform" *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP rep-format ) reportint= Requested Report Interval (plain-text; OPTIONAL; default is "0"). The value is an unsigned 32-bit integer that specifies an interval during which the report generator SHOULD NOT issue more than one report about a given type of incident should be generated. A value of "0" requests a report for every incident. Where the requested interval is not zero, the agent generating a Kucherawy & Fontana Expires July 11, 2011 [Page 9] Internet-Draft Auth Failure Reporting January 2011 report SHOULD include an "Incidents:" field in the generated report so the receiving agent has some indication of how many reports were suppressed. ABNF: spf-ri-tag = "reportint" *WSP "=" *WSP 1*DIGIT reportopts= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 6.3 for a list of valid tags. ABNF: spf-ro-type = ( "all" / "s" / "f" ) spf-ro-tag = "reportopts" *WSP "=" *WSP spf-ro-type *WSP 0* ( ":" *WSP spf-ro-type ) reportsmtp= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a string the signing domain requests be included in [SMTP] error strings when messages are rejected. ABNF: spf-rs-tag = "reportsmtp" *WSP "=" qp-section Kucherawy & Fontana Expires July 11, 2011 [Page 10] Internet-Draft Auth Failure Reporting January 2011 6. Requested Reports This memo also includes, as the "ro" tags defined above, the means by which the sender can request reports for specific circumstances of interest. Verifiers MUST NOT generate reports for incidents that do not match a requested report, and MUST ignore requests for reports not included in this these lists. 6.1. Requested Reports for DKIM Failures The following report requests are defined for DKIM keys: all All reports are requested. s Reports are requested for signature or key syntax errors. v Reports are requested for signature verification failures or body hash mismatches. x Reports are requested for signatures rejected by the verifier because the expiration time has passed. 6.2. Requested Reports for DKIM ADSP Failures The following report requests are defined for ADSP records: all All reports are requested. s Reports are requested for messages that have a valid [DKIM] signature but do not match the published [ADSP] policy. u Reports are requested for messages that have no valid [DKIM] signature but do not match the published [ADSP] policy. 6.3. Requested Reports for SPF Failures The following report requests are defined for SPF keys: all All reports are requested. f Reports are requested for messages that produced an SPF result of "fail". s Reports are requested for messages that produced an SPF result of "softfail". Kucherawy & Fontana Expires July 11, 2011 [Page 11] Internet-Draft Auth Failure Reporting January 2011 7. Reporting Formats This section lists reporting formats supported by this reporting mechanism. Currently only two formats are supported: arf: Abuse Reporting Format, as defined in [ARF], and as extended in Section 8. smtp: An [SMTP] error with a string descriptive of the problem that caused the sender authentication to fail. This explicitly requests evaluation of sender authentication concurrent with the SMTP session, and rejection (if appropriate) whenever possible rather than acceptance of the message and later generation of a feedback report of some kind (e.g. "arf" above) when verification fails. The presence of an "rs" tag (see Section 3 and Section 4) or "reportsmtp" tag (see Section 5) further requests a specific substring be included in the reply to ease automatic handling of such errors by sending or relaying MTAs. Kucherawy & Fontana Expires July 11, 2011 [Page 12] Internet-Draft Auth Failure Reporting January 2011 8. Extension ARF Fields for Authentication Failure Reporting The current ARF format defined in [ARF] lacks some specific features required to do effective sender authentication reporting. This section describes the extensions required to do so and thus required to conform to this specification. 8.1. New ARF Feedback Type A new feedback type of "auth-failure" is defined as an extension to Section 8.2 of [ARF]. See Section 8.3 for details. A message that uses this feedback type has the following modified header field requirements for the second (machine-parseable) MIME part of the report: Authentication-Results: This field MUST be formatted as defined in [AUTH-RESULTS], except that it MUST include explicit results for both DKIM and SPF even if those tests were not actually performed. This field MUST appear at least once, and it is RECOMMENDED that the corresponding header fields be copied directly from the message about which a report is being generated. Original-Envelope-Id: As specified in [ARF]. This field MUST appear exactly once. Original-Mail-From: As specified in [ARF]. This field MUST appear exactly once. Arrival-Date: As specified in [ARF]. This field MUST appear exactly once. Source-IP: As specified in [ARF]. This field MUST appear exactly once. If this information is either not available at the time the report is generated, or the generating ADMD's policy requires it be redacted, a value of 0.0.0.0 MUST be used. Message-ID: As specified in [ARF]. This field MUST appear exactly once. Reported-Domain: As specified in [ARF]. This field MUST appear exactly once. Delivery-Result: As specified in Section 8.2.1. This field MUST appear exactly once. For privacy reasons, report generators might need to redact portions of a reported message such as the end user whose complaint action Kucherawy & Fontana Expires July 11, 2011 [Page 13] Internet-Draft Auth Failure Reporting January 2011 resulted in the report. See Section 10 for a discussion of this. 8.2. New ARF Header Field Names The following new ARF field names are defined as extensions to Section 6.2 of [ARF]. The values that are base64 encodings may contain FWS for formatting purposes as per the usual header field wrapping defined in [MAIL]. During decoding, any characters not in the base64 alphabet are ignored so that such line wrapping does not harm the value. The ABNF token "FWS" is defined in [DKIM]. 8.2.1. Required For All Reports Auth-Failure: Indicates the type of authentication failure that is being reported. The list of valid values is enumerated below. Delivery-Result: The final message disposition that was enacted by the ADMD generating the report. Possible values are: inbox: The message was delivered to the intended inbox. spam: The message was delivered to the recipient's spam folder (or equivalent). policy: The message was not delivered to the intended inbox due to authentication failure. The specific action taken is not specified. reject: The message was rejected. other: The message had a final disposition not covered by one of the above values. 8.2.2. Required For DKIM Reports DKIM-Canonicalized-Header: A base64 encoding of the canonicalized header of the message as generated by the verifier. DKIM-Domain: The domain that signed the message, taken from the "d=" tag of the signature. DKIM-Identity: The identity of the signature that failed verification, taken from the "i=" tag of the signature. Kucherawy & Fontana Expires July 11, 2011 [Page 14] Internet-Draft Auth Failure Reporting January 2011 DKIM-Selector: The selector of the signature that failed verification, taken from the "s=" tag of the signature. 8.2.3. Optional For DKIM Reports DKIM-ADSP-DNS: The contents of the DNS TXT record retrieved when trying to determine the author domain's signing practices via the protocol defined in [ADSP]. DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body of the message as generated by the verifier. This header and value MUST be present for reports using feedback type "dkim" when reporting a "bodyhash" failure. DKIM-Selector-DNS: The contents of the DNS TXT record retrieved when trying to evaluate the DKIM signature (i.e. a TXT record whose name is assembled from the signature's "s=" and "d=" tags). 8.2.4. Optional For SPF Reports SPF-DNS: The contents of the SPF policy record retrieved from a TXT record in the DNS during SPF evaluation. 8.3. Authentication Failure Types The list of defined authentication failure types, used in the "Auth- Failure:" header (defined above), is as follows: adsp: The message did not conform to the sender's published [ADSP] signing practises. The DKIM-ADSP-DNS field MUST be included in the report. bodyhash: The body hash in the signature and the body hash computed by the verifier did not match. The DKIM-Canonicalized-Body field SHOULD be included in the report. granularity: The DKIM key referenced by the signature on the message was not authorized for use by the sender. The DKIM-Domain and DKIM-Selector fields MUST be included in the report, and the DKIM- Identity field SHOULD be included. revoked: The DKIM key referenced by the signature on the message has been revoked. The DKIM-Domain and DKIM-Selector fields MUST be included in the report. Kucherawy & Fontana Expires July 11, 2011 [Page 15] Internet-Draft Auth Failure Reporting January 2011 signature: The DKIM signature on the message did not successfully verify against the header hash and public key. The DKIM-Domain, DKIM-Selector and DKIM-Canonicalized-Header fields MUST be included in the report. spf: The evaluation of the sending domain's SPF record produced a "fail" or "softfail" result. Supplementary data may be included in the form of [MAIL]-compliant comments. For example, "Failure: adsp" could be augmented by a comment to indicate that the failed message was rejected because it was not signed when it should have been. See Appendix B for examples. Kucherawy & Fontana Expires July 11, 2011 [Page 16] Internet-Draft Auth Failure Reporting January 2011 9. Syntax For Added Fields The ABNF definitions for the new fields are as follows: auth-failure = "Auth-Failure:" [CFWS] token [CFWS] CRLF ; "token" must be a registered authentication failure type ; as specified elsewhere in this memo delivery-result = "Delivery-Result:" [CFWS] ( "inbox" / "spam" / "policy" / "reject" / "other" ) [CFWS] CRLF dkim-header = "DKIM-Canonicalized-Header:" [CFWS] base64string CRLF ; "base64string" is imported from [DKIM] dkim-domain = "DKIM-Domain:" [CFWS] domain [CFWS] CRLF dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@" domain-name [CFWS] CRLF ; "local-part" is imported from [MAIL] dkim-selector = "DKIM-Selector:" [CFWS] token [CFWS] CRLF dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS] quoted-string [CFWS] CRLF ; "quoted-string" is imported from [MAIL] dkim-body = "DKIM-Canonicalized-Body:" [CFWS] base64string CRLF dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS] quoted-string [CFWS] CRLF spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF Kucherawy & Fontana Expires July 11, 2011 [Page 17] Internet-Draft Auth Failure Reporting January 2011 10. Redacting Data For privacy considerations it might be the policy of a report generator to redact, or obscure, portions of the report that might identify an end user that caused the report to be generated. Precisely how this is done is unspecified in [ARF] as it will generally be a matter of local policy. That specification does admonish generators against being too over-zealous with this practice, as obscuring too much data makes the report inactionable. Previous redaction practices, such as replacing local-parts of addresses with a uniform string like "xxxxxxxx", often frustrated any kind of prioritizing or grouping of reports. Generally, it is assumed that the recipient fields of a message, when copied into a report, are to be obscured to protect the identify of an end user that submitted a complaint about a message. However, it is also presumed that other data will be left intact, data that could be correlated against logs to determine the source of the message that drew a complaint. To enable correlation of reports that might refer to a common but anonymous source, the following redaction practice is recommended: 1. Select an arbitrary string that will be used by an ADMD that generates reports. This string will not be changed except according to a key rotation policy or similar. Call this the "redaction key". 2. Identify string(s) (such as local-parts of email addresses) in a message that need to be redacted. Call this the "private data". 3. Construct a new string that is a copy of the redaction key with the private data concatenated to it. 4. Compute a digest of that string with any hashing/digest algorithm such as SHA1. 5. Encode that hash with the base64 algorithm as defined in [MIME]. 6. Replace the private data with the encoded hash when generating the report. This has the effect of obscuring the data in an irreversible way but still allows the report recipient to observe that numerous reports are about one particular end user. Such detection enables the receiver to prioritize its reactions based on problems that appear to be focused on specific end users that may be under attack. Kucherawy & Fontana Expires July 11, 2011 [Page 18] Internet-Draft Auth Failure Reporting January 2011 11. IANA Considerations As required by [IANA-CONSIDERATIONS], this section contains registry information for the new [DKIM] key tags, the new [ADSP] tags, the new [SPF] tags, and the extensions to [ARF]. 11.1. DKIM Key Tag Registration IANA is requested to update the DKIM Key Tag Specification Registry to include the following new items: +------+-----------------+ | TYPE | REFERENCE | +------+-----------------+ | r | (this document) | | rf | (this document) | | ri | (this document) | | ro | (this document) | | rs | (this document) | +------+-----------------+ 11.2. DKIM ADSP Tag Registration IANA is requested to update the DKIM ADSP Tag Specification Registry to include the following new items: +------+-----------------+ | TYPE | REFERENCE | +------+-----------------+ | r | (this document) | | rf | (this document) | | ri | (this document) | | ro | (this document) | | rs | (this document) | +------+-----------------+ 11.3. SPF Tag Registration IANA is requested to create the Sender Policy Framework Modifier Registry, to include a list of all registered SPF modifier names and their defining documents. New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA-CONSIDERATIONS]. New registrations and updates MUST contain the following information: Kucherawy & Fontana Expires July 11, 2011 [Page 19] Internet-Draft Auth Failure Reporting January 2011 1. Name of the modifier being registered or updated 2. The document in which the specification of the modifier is published 3. New or updated status, which MUST be one of: current: The field is in current use deprecated: The field is in current use but its use is discouraged historic: The field is no longer in current use An update may make a notation on an existing registration indicating that a registered field is historic or deprecated if appropriate. +------------+-----------------+---------+ | MODIFIER | REFERENCE | STATUS | +------------+-----------------+---------+ | exp | RFC4408 | current | | redirect | RFC4408 | current | | report | (this document) | current | | reportform | (this document) | current | | reportint | (this document) | current | | reportopts | (this document) | current | | reportsmtp | (this document) | current | +------------+-----------------+---------+ 11.4. Updates to ARF Feedback Types The following feedback type is added to the Feedback Report Feedback Type Registry: Feedback Type: auth-failure Description: sender authentication failure report Registration: (this document) 11.5. Updates to ARF Header Field Names The following headers are added to the Feedback Report Header Names Registry: Field Name: Auth-Failure Description: Type of authentication failure Multiple Appearances: No Related "Feedback-Type": auth-failure Kucherawy & Fontana Expires July 11, 2011 [Page 20] Internet-Draft Auth Failure Reporting January 2011 Field Name: Delivery-Result Description: Final disposition of the subject message Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-ADSP-DNS Description: Retrieved DKIM ADSP record Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Canonicalized-Body Description: Canonicalized body, per DKIM Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Canonicalized-Header Description: Canonicalized header, per DKIM Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Domain Description: DKIM signing domain from "d=" tag Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Identity Description: Identity from DKIM signature Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Selector Description: Selector from DKIM signature Multiple Appearances: No Related "Feedback-Type": auth-failure Field Name: DKIM-Selector-DNS Description: Retrieved DKIM key record Multiple Appearances: No Related "Feedback-Type": auth-failure Kucherawy & Fontana Expires July 11, 2011 [Page 21] Internet-Draft Auth Failure Reporting January 2011 Field Name: SPF-DNS Description: Retrieved SPF record Multiple Appearances: No Related "Feedback-Type": auth-failure Kucherawy & Fontana Expires July 11, 2011 [Page 22] Internet-Draft Auth Failure Reporting January 2011 12. Security Considerations Security issues with respect to these reports are similar to those found in [DSN]. 12.1. Inherited Considerations Implementors are advised to consider the Security Considerations sections of [DKIM], [ADSP] [SPF] and [ARF]. 12.2. Forgeries These reports may be forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of DSNs of any kind should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged DSNs include the sending of: a. A falsified authentication failure notification when the message was in fact delivered to the indicated recipient; b. Falsified signature information, such as selector, domain, etc. Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM. On the other hand, if there's a problem with the DKIM infrastructure at the verifier, signing DKIM failure reports may produce reports that aren't trusted or even accepted by their intended recipients. 12.3. Automatic Generation Automatic generation of these reports by verifying agents can cause a denial-of-service attack when a large volume of e-mail is sent that causes sender authentication failures for whatever reason. Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information. In general ARF feedback loop terms, it is suggested that report generators only create these (or any) ARF reports after an out-of- band arrangement has been made between two parties. This mechanism then becomes a way to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement rather than starting to send them automatically based solely on Kucherawy & Fontana Expires July 11, 2011 [Page 23] Internet-Draft Auth Failure Reporting January 2011 discovered data in the DNS. 12.4. Envelope Sender Selection In the case of transmitted reports in the form of a new message, it is necessary to construct the message so as to avoid amplification attacks, deliberate or otherwise. Thus, per Section 2 of [DSN], the envelope sender address of the report SHOULD be chosen to ensure that no delivery status reports will be issued in response to the report itself, and MUST be chosen so that these reports will not generate mail loops. Whenever an [SMTP] transaction is used to send a report, the MAIL FROM command MUST use a NULL return address, i.e. "MAIL FROM:<>". 12.5. Reporting Multiple Incidents If it is known that a particular host generates abuse reports upon certain incidents, an attacker could forge a high volume of messages that will trigger such a report. The recipient of the report could then be innundated with reports. This could easily be extended to a distributed denial-of-service attack by finding a number of report- generating servers. The incident count referenced in [ARF] provides a limited form of mitigation. The host generating reports may elect to send reports only periodically, with each report representing a number of identical or near-identical incidents. One might even do something inverse-exponentially, sending reports for each of the first ten incidents, then every tenth incident up to 100, then every 100th incident up to 1000, etc. until some period of relative quiet after which the limitation resets. The use of this for "near-identical" incidents in particular causes a degradation in reporting quality, however. If for example a large number of pieces of spam arrive from one attacker, a reporting agent may decide only to send a report about a fraction of those messages. While this averts a flood of reports to a system administrator, the precise details of each incident are similarly not sent. Kucherawy & Fontana Expires July 11, 2011 [Page 24] Internet-Draft Auth Failure Reporting January 2011 13. References 13.1. Normative References [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM Sender Signing Practises", RFC 5617, August 2009. [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. [AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. 13.2. Informative References [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. Kucherawy & Fontana Expires July 11, 2011 [Page 25] Internet-Draft Auth Failure Reporting January 2011 Appendix A. Acknowledgements The authors wish to acknowledge the following for their review and constructive criticism of this proposal: Monica Chew, Tim Draegen and JD Falk. Kucherawy & Fontana Expires July 11, 2011 [Page 26] Internet-Draft Auth Failure Reporting January 2011 Appendix B. Examples This section contains examples of the use of each of the extensions defined by this memo. B.1. Example Use of DKIM Key Extension Tags A DKIM key record including use of the extensions defined by this memo: v=DKIM1; k=rsa; t=y; r=dkim-errors; rf=arf; ro=v:x; p=MIGfMA0GCS qGSIb3DQEBAQUAA4GNADCBiQKBgQDh2vbhJTijCs2qbyJcwRCa8WqDTxI+PisFJo faPtoDJy0Qn41uNayCajfKADVcLqc87sXQS6GxfchPfzx7Vh9crYdxRbN/o/URCu ZsKmym1i1IPTwRLcXSnuKS0XDs1eRW2WQHGYlXksUDqSHWOS3ZO1W5t/FLcZHpIl l/80xs4QIDAQAB Example 1: DKIM key record using these extensions This example DKIM key record contains the following data in addition to the basic DKIM key data: o Reports about signature evaluation failures should be send to the address "dkim-errors" at the sender's domain; o The sender's domain requests reports in the "arf" format; o Only reports about signature verification failures and expired signatures should be generated. B.2. Example Use of DKIM ADSP Extension Tags A DKIM ADSP record including use of the extensions defined by this memo: dkim=all; r=dkim-adsp-errors; rf=arf; ro=u Example 2: DKIM ADSP record using these extensions This example ADSP record makes the following assertions: o The sending domain (i.e. the one that is advertising this policy) signs all mail it sends; o Reports about ADSP evaluation failures should be send to the address "dkim-adsp-errors" at the sender's domain; o The sender's domain requests reports in the "arf" format; Kucherawy & Fontana Expires July 11, 2011 [Page 27] Internet-Draft Auth Failure Reporting January 2011 o Only reports about unsigned messages should be generated. B.3. Example Use of ARF Extension Headers An ARF-formatted report using some of the proposed ARF extension fields: From: arf-daemon@example.com To: recipient@example.net Subject: This is a test Date: Wed, 14 Apr 2010 12:17:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary" --part1_13d.2e68ed54_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is an email abuse report for an email message received from IP 192.0.2.1 on Wed, 14 Apr 2010 12:15:31 PDT. For more information about this format please see http://www.mipassoc.org/arf/. --part1_13d.2e68ed54_boundary Content-Type: message/feedback-report Feedback-Type: auth-failure User-Agent: SomeDKIMFilter/1.0 Version: 1.0 Original-Mail-From: Original-Rcpt-To: Received-Date: Wed, 14 Apr 2010 12:15:31 -0700 (PDT) Source-IP: 192.0.2.1 Authentication-Results: mail.example.com; dkim=fail header.d=example.net Reported-Domain: example.net DKIM-Domain: example.net DKIM-Failure: bodyhash --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256; s=testkey; d=example.net; h=From:To:Subject:Date; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut Kucherawy & Fontana Expires July 11, 2011 [Page 28] Internet-Draft Auth Failure Reporting January 2011 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4= Received: from smtp-out.example.net by mail.example.com with SMTP id o3F52gxO029144; Wed, 14 Apr 2010 12:15:31 -0700 (PDT) Received: from internal-client-001.example.com by mail.example.com with SMTP id o3F3BwdY028431; Wed, 14 Apr 2010 12:12:09 -0700 (PDT) From: randomuser@example.net To: user@example.com Date: Wed, 14 Apr 2010 12:12:09 -0700 (PDT) Subject: This is a test Hi, just making sure DKIM is working! --part1_13d.2e68ed54_boundary-- Example 3: Example ARF report using these extensions This example ARF message is making the following assertion: o DKIM verification of the signature added within "example.net" failed when it was processed on arrival at "mail.example.com". o The cause for the verification failure was a mismatch between the body contents observed at the verifier and the body hash contained in the signature. Kucherawy & Fontana Expires July 11, 2011 [Page 29] Internet-Draft Auth Failure Reporting January 2011 Appendix C. Public Discussion [REMOVE BEFORE PUBLICATION] Public discussion of this proposed specification is handled via the mail-vet-discuss@mipassoc.org mailing list. The list is open. Access to subscription forms and to list archives can be found at http://mipassoc.org/mailman/listinfo/mail-vet-discuss. Kucherawy & Fontana Expires July 11, 2011 [Page 30] Internet-Draft Auth Failure Reporting January 2011 Authors' Addresses Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US Phone: +1 415 946 3800 Email: msk@cloudmark.com Hilda Fontana eCert Systems One Market St., Suite 3600 San Francisco, CA 94105 US Phone: +1 415 681 8000 Email: hfontana@ecertsystems.com Kucherawy & Fontana Expires July 11, 2011 [Page 31]