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.
[]
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]