Individual submission M. Kucherawy Internet-Draft Sendmail, Inc. Intended status: Standards Track November 2007 Expires: May 4, 2008 Reporting of DKIM Verification Failures draft-kucherawy-dkim-reporting-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kucherawy Expires May 4, 2008 [Page 1] Internet-Draft DKIM Reporting November 2007 Abstract This memo presents an amendment to the DomainKeys Identified Mail (DKIM) specification to allow public keys for verification to include a reporting address to be used to report verification issues, and an Internet Message format to be followed when generating such reports. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Works . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Optional Key Reporting Address . . . . . . . . . . . . . . . . 4 3. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. message/dkim-report Format . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. r= Key Tag Registration . . . . . . . . . . . . . . . . . 9 5.2. message/dkim-report MIME Type Registration . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Automatic Generation . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 14 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Kucherawy Expires May 4, 2008 [Page 2] Internet-Draft DKIM Reporting November 2007 1. Introduction [DKIM] introduced a standard for digital signing of messages for the purposes of sender authentication. There exist cases in which a domain name owner might want to receive reports from verifiers that determine DKIM-signed mail apparently from its domain is failing to verify according to [DKIM] or is "Suspicious" according to [I-D.DRAFT-IETF-DKIM-SSP]. This document amends [DKIM] to add an optional reporting address to selector records, and specifies a format to be used when generating such reports. 1.1. Related Works [I-D.DRAFT-SHAFRANOVICH-FEEDBACK-REPORT] introduces a similar reporting format. However, it is more focused on the origins and envelope of the message, such as the source IP address, original envelope sender and recipient, etc., and is clearly intended to report about abuse and other similar conditions. Little or none of this information is pertinent to a DKIM verification failure report. Moreover, a DKIM failure report may need to contain more information than a simple [REPORT] allows. Thus a new report type more specific to the requirements of reporting signature verification failures is desired. 1.2. Definitions 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. Kucherawy Expires May 4, 2008 [Page 3] Internet-Draft DKIM Reporting November 2007 2. Optional Key Reporting Address There exist cases in which a domain name owner employing [DKIM] for e-mail signing and authentication may 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 "tag" (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 the local-part of 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 MUST be as defined in Section 3 of this document. 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. Kucherawy Expires May 4, 2008 [Page 4] Internet-Draft DKIM Reporting November 2007 3. Reporting Format Both Section 2 of this document and [I-D.DRAFT-IETF-DKIM-SSP] define the means by which a sender or signer advertising either signing practises or a key for verifying messages can indicate to verifiers that the sender or signer would like to receive reports about anomalous messages. In particular, Section 2 requests that information when messages fail verification using specific keys, and [I-D.DRAFT-IETF-DKIM-SSP] requests reports for messages which arrive unsigned. A regular report format akin to [DSN] is desirable. In addition to the general utility of having such reports be in a predictable format, this specification introduces guidance as to the useful content of such reports. The format of the report message conforms to [REPORT] and thus is a [MIME] message whose overall MIME type is "multipart/report". The first MIME part is a human-readable description of what is being reported and why. The agent generating this report as a result of a DKIM event SHOULD describe the purpose of the report (SSP violation, key verification failure, etc.). The generating agent MAY include such information as the values of the "d=" and "s=" portions of the signature (if the message was signed) and/or the value of the From: header field of the message whose failed verification caused the report. The second MIME part is of type "message/dkim-report", defined in Section 4. It is a machine parsable collection of information comprising an account of the failed verification event. The purpose of these data is to provide details supplementary to those in the first part that may be useful to human experts. The third MIME part is of type "multipart/mixed", since [REPORT] restricts reports to contain no more than three parts. This third MIME part consists of the following sub-parts: 1. A REQUIRED part of type "text/rfc822-headers" which contains the complete header of the message which failed verification. 2. A part of type "text/plain" which contains the base64 encoding of the canonicalized message header as reconstructed by the verifier. This part is REQUIRED if the message generating the report was signed. 3. An optional part of type "text/plain" which contains the base64 encoding of the canonicalized body as reconstructed by the Kucherawy Expires May 4, 2008 [Page 5] Internet-Draft DKIM Reporting November 2007 verifier. This part SHOULD be included, but may be omitted if the computed body hash and the body hash present in the message signature matched (indicating no body modification was detected in transit). 4. An optional part of type "text/plain" which contains supplementary diagnostic information of any kind that the verifier wishes to return to the reported address. Any sort of forensic analysis, such as comparison of the "z=" tag's value (if any) to the received message's header fields may be included here. This text is free-form. Kucherawy Expires May 4, 2008 [Page 6] Internet-Draft DKIM Reporting November 2007 4. message/dkim-report Format This section defines the new "message/dkim-report" MIME media type, used to construct the second MIME part of the overall report message. The content of this type is entirely 7-bit US-ASCII text identical to the restrictions set out in section 2.8 of [MIME]. It consists of a number of lines of text of the following form: line = parameter ":" [CFWS] value [CFWS] CRLF CFWS is as defined in section 3.2.3 of [MAIL]. A "parameter" and corresponding possible values are defined as follows: Authentication-Results: (OPTIONAL) The value of an Authentication- Results: header, as defined in [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER], which was or would be added by the verifier upon delivery of the message (obviously indicating the reason for the DKIM failure). Domain: (REQUIRED if the message was signed) The value of the "d=" tag in the message signature. Failure: (REQUIRED) One of the following strings: bodyhash: The body hash in the signature and the body hash computed by the verifier did not match. granularity: The key referenced by the signature on the message was not authorized for use by the sender. revoked: The key referenced by the signature on the message has been revoked. signature: The signature on the message did not successfully verify against the header hash and public key. ssp: The sender's published signing practises determined the message is suspicious. Identity: (REQUIRED if the message was signed and an explicit "i=" tag was present) The value of the "i=" tag in the message signature. Selector: (REQUIRED if the message was signed) The value of the "s=" tag in the message signature. Supplementary data may be included in the form of [MAIL]-compliant Kucherawy Expires May 4, 2008 [Page 7] Internet-Draft DKIM Reporting November 2007 comments. For example, "Failure: ssp" 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 Expires May 4, 2008 [Page 8] Internet-Draft DKIM Reporting November 2007 5. IANA Considerations As required by [IANA-CONSIDERATIONS], this section contains registry information for the new [DKIM] key tag and the new [MIME2] media type defined by this specification. 5.1. r= Key Tag Registration IANA is requested to update the DKIM Key Tag Specification Registry to include the following new item: +------+-----------------+ | TYPE | REFERENCE | +------+-----------------+ | r | (this document) | +------+-----------------+ 5.2. message/dkim-report MIME Type Registration MIME media type name: message MIME subtype name: dkim-report Required parameters: (none) Optional parameters: (none) Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: Described in Section 6 of this document. Interoperability considerations: (none) Published specification: (this document) Applications which use this media type: DKIM verification agents Additional information: For additional information, contact the author of this document. Contact information is provided toward the end of the document. Person & email address to contact for further information: For further information, contact the author of this document. Contact information is provided toward the end of the document. Kucherawy Expires May 4, 2008 [Page 9] Internet-Draft DKIM Reporting November 2007 Intended usage: COMMON Author/Change controller: Author contact information is provided toward the end of the document. The author is also the change controller of this media type. Kucherawy Expires May 4, 2008 [Page 10] Internet-Draft DKIM Reporting November 2007 6. Security Considerations Security issues with respect to these DKIM reports are similar to those found in [DSN]. 6.1. 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 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 DKIM 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 DKIM reports should themselves be signed. This is under consideration. 6.2. 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 DKIM verification failures for whatever reason. It is unclear what a good solution for this issue is. Limiting the rate of generation of these messages may be apropos but threatens to inhibit the distribution of important and possibly time-sensitive information. Kucherawy Expires May 4, 2008 [Page 11] Internet-Draft DKIM Reporting November 2007 7. References 7.1. Normative References [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4817, May 2007. [I-D.DRAFT-IETF-DKIM-SSP] Allman, E., Delany, M., and J. Fenton, "DKIM Sender Signing Practises", I-D draft-ietf-dkim-ssp-01. [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. [MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. 7.2. Informative References [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", I-D draft-kucherawy-sender-auth-header-09, November 2007. [I-D.DRAFT-SHAFRANOVICH-FEEDBACK-REPORT] Shafranovich, Y., Levine, J., and P. Hoffman, "An Extensible Format for Email Feedback Reports", I-D draft-shafranovich-feedback-report-03, June 2007. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. Kucherawy Expires May 4, 2008 [Page 12] Internet-Draft DKIM Reporting November 2007 Appendix A. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this proposal: (add names here) Kucherawy Expires May 4, 2008 [Page 13] Internet-Draft DKIM Reporting November 2007 Appendix B. Examples FOO BAR BAZ BLIVIT Kucherawy Expires May 4, 2008 [Page 14] Internet-Draft DKIM Reporting November 2007 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 Expires May 4, 2008 [Page 15] Internet-Draft DKIM Reporting November 2007 Author's Address Murray S. Kucherawy Sendmail, Inc. 6475 Christie Ave., Suite 350 Emeryville, CA 94608 US Phone: +1 510 594 5400 Email: msk+ietf@sendmail.com Kucherawy Expires May 4, 2008 [Page 16] Internet-Draft DKIM Reporting November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kucherawy Expires May 4, 2008 [Page 17]