Internet DRAFT - draft-santos-dkim-rcvd
draft-santos-dkim-rcvd
DKIM Working Group H. Santos
Internet-Draft Santronics Software, Inc.
Intended status: Experimental April 23, 2006
Expires: October 25, 2006
Partial DKIM Verifier Support using a DKIM-Received Trace Header
draft-santos-dkim-rcvd-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.
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 Notice
Copyright (C) The Internet Society (2006).
Abstract
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Santos Expires October 25, 2006 [Page 1]
Internet-Draft DKIM-Received April 2006
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background/Problem . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Summary: Partial Verifier Support . . . . . . . . . . 5
4. How it works? . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Santos Expires October 25, 2006 [Page 2]
Internet-Draft DKIM-Received April 2006
1. Introduction
DKIM [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.
2. Background/Problem
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:
Santos Expires October 25, 2006 [Page 3]
Internet-Draft DKIM-Received April 2006
-------------- -----------------
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] [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] [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.
Santos Expires October 25, 2006 [Page 4]
Internet-Draft DKIM-Received April 2006
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.
3. Solution Summary: Partial Verifier Support
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
[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:
o Partial Verifiers MUST add DKIM-Received header.
o Full Verifiers MAY add DKIM-Received header.
o The sd= tag MUST include the p=data tag. It MAY include other or
all tags in record. However, all that is required is the public-
key (p=data).
o The optional vt= tag is added by FULL verifiers only.
o DKIM-timestamps are in a format deemed acceptable by the DKIM
protocol (i.e., easy extraction, easy parsing, Y2K compliant).
Santos Expires October 25, 2006 [Page 5]
Internet-Draft DKIM-Received April 2006
4. How it works?
As an organization is migrating to full DKIM support, it may decide
to add partial verification support by performing the following
steps:
1. If a incoming message has a DKIM-Signature, obtain the selector
and domain from the s= and d= tag respectively.
2. Obtain the public key by performing DKIM DNS query on
selector._domainkey.<domain>.
3. Create and prepend the DKIM-Received: header setting the rt=
received time and the sd= tag with the public key data. The
DKIM-Received MUST be written before the SMTP required Received:
Header is written.
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:
1. If the DKIM-Signature: has a x= expiration tag, check for a DKIM-
Received: header and use the rt= received time stamp for time
comparison.
2. If no x= expiration is available, begin the DKIM verification by
obtaining the public key from DNS.
3. If no public key is available, it MAY verify the signature by
using the public key (sd=) recorded in the DKIM-Received: header,
if any.
5. Example
The following example shows what a MDA would add to the incoming
message:
Santos Expires October 25, 2006 [Page 6]
Internet-Draft DKIM-Received April 2006
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;
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
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.
8. Acknowledgements
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.
9. Normative References
[DKIM-BASE]
Allman, E., "DomainKeys Identified Mail Signatures",
April 2006, <http://mipassoc.org/dkim/specs/
draft-allman-dkim-base-01.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
Santos Expires October 25, 2006 [Page 7]
Internet-Draft DKIM-Received April 2006
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
Author's Address
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
Santos Expires October 25, 2006 [Page 8]
Internet-Draft DKIM-Received April 2006
Full Copyright Statement
Copyright (C) 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.
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).
Santos Expires October 25, 2006 [Page 9]
