| TOC |
|
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.
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 October 25, 2006.
Copyright © The Internet Society (2006).
A proposal offering partial DKIM verification support to help resolve premature DKIM signature expiration and key revocation related problems associated with time shifted DKIM verifier applications.
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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
2.
Background/Problem
3.
Solution Summary: Partial Verifier Support
4.
How it works?
5.
Example
6.
IANA Considerations
7.
Security Considerations
8.
Acknowledgements
9.
Normative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
DKIM (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [DKIM‑BASE] (Domain Keys Identified Message) has a potential premature signature expiration timing issue related to when DKIM verifiers receive a message and when domain signature expire and/or when public keys are revoked.
The problem is highlighted when the DKIM verifiers is outside the SMTP transport such as MUAs and the backend software (MDA) does not support DKIM.
This document offers a proposal and solution to the problem whereby a MDA can offer partial DKIM verification support by adding a new trace header called DKIM-Received recording the DKIM domain DNS public key information before it expired or is revoked.
| TOC |
Some where along the email transport topology path when sending mail between point A and point B, we have DKIM signer(s) and DKIM verifier(s). This generalized commonly understood email topology can be illustrated in the following diagram:
-------------- --------------
MUA --> | MSA--->MTA | -----> | MDA--->MFA | ---> MUA
-------------- --------------
\____________________/ \_____________________/
DKIM SIGNER DKIM VERIFIER| Figure 1: Typical Mail Flow Topology |
The DKIM signer may be the MUA sending the message to the MSA or within a MSA/MTA network signing messages on behalf of the MUA. The DKIM verifier may be located at the MDA, MFA or recipient MUA.
The MFA (Mail Filtering Agent) is a new acronym describing a relatively recent industry direction and practice to include anti-virus/spam (AVS) mail filtering processes within the MDA network. The MFA could be a SIEVE process, SPAM-ASSASSIN or some non-standard proprietary Rule Based Messaging (RBM) scripting engine. The MFA is any process that is outside the SMTP transport process after the message is accepted by the MDA and before it is stored in the recipient MUA user's mail box.
This provides us with three possible verification delays, t1, t2, and t3, which can promote premature signature expiration or key revocation timing issues depending on where the DKIM verifier is located:
-------------- -----------------
MUA --> | MSA--->MTA | --t1--> | MDA--t2-->MFA | --t3--> MUA
-------------- -----------------| Figure 2: Typical Mail Flow Topology with Delays |
The latter two are time shifted applications because message validation is belated or delayed.
The t1 delay is the SMTP transport time from MTA to MDA. SMTP has a recommended limit of 4-5 days for a SMTP sending/retry strategy [RFC 2821 section 4.5.4.1] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [RFC2821]. DKIM has a recommended seven (7) day retention limit. So for t1, there would be a low occurrence of premature signature expiration problems at the MDA. The DKIM recommendation of seven days is sufficient and covers the SMTP 4-5 day retry limit recommendation.
However, premature expiration potential increases once the MDA accepts the message and verification may occur at the MFA or MUA.
The length of the MFA delay (t2) is directly proportional to the volume of mail being received (high volume system), and the higher the volume, scalarability operational considerations will typically mandate that the DKIM verification process begin after the message is accepted.
The length of the MUA delay (t3) is directly proportional to the MUA ergonomics and user behavior in regards to frequency of mail pickup or frequency of user logins in order to download, read or received new mail.
In short, the potential of premature DKIM expiration problems increase as the verification process is time shifted beyond MDA applications.
To help resolve this, one possible idea is allow the MFA and MUA to use the time stamp recorded at the MDA as required by the all SMTP receivers when adding the Received: trace header [RFC 2821 section 4.4] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [RFC2821]. This time stamp may be called the Transaction Reception Time (TRT) because it represents the time the MDA first received the transaction from the MTA. If the MFA and MUA use the TRT as part of the DKIM expiration checks, the problems related to signature expirations are eliminated.
However, while using the TRT may help resolve MFA and MUA timing issues, there is still the possibility of a DKIM public key being revoked or removed from DNS.
To help resolve this problem, a new idea called "Partial Verifier DKIM support" may be used by MDA verifiers to help resolve both expiration or keys revocation problems potentially occurring at the MFA and much greater potential at the MUA.
| TOC |
In practice, it is conceivable for DKIM implementations to operate in a partial or full verifier support mode..
Partial Verifier support may include early adopters migrating towards full support and wanting to assist independent Full Verifier support processes, such as MFAs and MUAs, while the backend is being upgraded for full DKIM support.
Partial (including full) verifier support would begin with the simple addition of adding public key information in the new message RFC2822 (Resnick, P., “Internet Message Format,” April 2001.) [RFC2822] header called DKIM-Received:
DKIM-Received: rt=<DKIM-timestamp>; # Current time msg was received. sd=<selector-data>; # Selector DNS record Data. [vt=<DKIM-timestamp>;] # Current time msg was validated.
| Figure 3: DKIM-Received: Header |
If available, this header allows for time shifted full verifiers to obtain message state information that might be missing at a future moment of time to correctly validate a DKIM signature.
Semantics:
| TOC |
As an organization is migrating to full DKIM support, it may decide to add partial verification support by performing the following steps:
The full verifier MAY support DKIM-Received: If the full verifiers attempts to validate the signature, it MAY add the vt= verification time stamp tag. Adding the vt= tag to the DKIM-Received MUST NOT be viewed by MFA or MUAs as an indication of success or failure. It merely indicates that a verification was performed.
MFA and MUAs MAY support the DKIM-Received: header and if supported, it MAY use the public key information to validate the signature. The recommended steps are:
| TOC |
The following example shows what a MDA would add to the incoming message:
Example 5.1
Received: from sb10.example.com ([202.134.19.231])
by winserver.com (Wildcat! SMTP v6.1.451.7) with ESMTP
id 2671734859; Sat, 22 Apr 2006 12:28:31 -0400
DKIM-Received: rt=1145722498;
sd=p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALRW7ct
LniHlMlENXl0cW98CU9LqiI2vk0Dy42Wmg7jzJk/Phf1QHu
8ykUG8BMCagx7nPCWmT51FeqgmCqrb4475jZmNVg6TR4NQ9;
| TOC |
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
| TOC |
Other than not enforcing the key revocation concept. i.e. verification is still possible after the domain's public key is revoked, there are no security concerns currently envision with this proposal at this time.
| TOC |
Discussions related to signature expiration and key revocation timing problems in the IETF-DKIM Working Group among many participants lead to the development of this proposed solution.
| TOC |
| [DKIM-BASE] | Allman, E., “DomainKeys Identified Mail Signatures,” April 2006. |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2821] | Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001. |
| [RFC2822] | Resnick, P., “Internet Message Format,” RFC 2822, April 2001. |
| TOC |
| Hector Santos | |
| Santronics Software, Inc. | |
| 15600 SW 158 ST Suite #306 | |
| Homestead, Florida, FL 33033 | |
| United States of America | |
| Email: | hsantos@isdg.net |
| URI: | http://www.isdg.net |
| TOC |
Copyright © The Internet Society (2006).
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 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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).