Individual Submission J. Fenton
Internet-Draft Cisco Systems, Inc.
Intended status: Experimental February 12, 2009
Expires: August 16, 2009
DKIM Reputation Hint Extension
draft-fenton-dkim-reputation-hint-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 16, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract
This document defines an extension to the DomainKeys Identified Mail
(DKIM) specification to provide an identifier that may be used as a
Fenton Expires August 16, 2009 [Page 1]
Internet-Draft DKIM Reputation Hint February 2009
"hint" by reputation services using DKIM wanting to maintain
reputation information at a finer level of granularity than that of
the signing domain itself.
1. Introduction
DomainKeys Identified Mail (DKIM) [RFC4871] defines a simple, low
cost, and effective mechanism by which email messages can be
cryptographically signed, permitting a signing domain to claim
responsibility for the use of a given email address. Message
recipients can verify the signature by querying the signer's domain
directly to retrieve the appropriate public key, and thereby confirm
that the message was attested to by a party in possession of the
private key for the signing domain.
A frequently cited use for email authentication is that it provides a
basis for associating a reputation with the entity claiming
responsibility for the message. One way to do this is to associate
the reputation with the signing domain itself (the d= value in the
DKIM-Signature header field). However, many have expressed the
desire to provide more fine-grained information to aid reputation
maintainers and users in classifying their mail in a more detailed
manner.
Several use cases have been proposed for identifiers of this sort:
o A domain that supports multiple email addresses (personas) per
user may want to apply the same label to all messages from that
user so that an aggregate reputation of all of that user's
messages may accrue.
o A domain with a mixture of premium accounts (for which they
charge) and free accounts may want to label mail from those
accounts differently because of the higher potential for abuse of
the free accounts.
o A domain with a mixture of transactional and other mail may decide
to label the transactional mail separately from the other mail
because of the low potential of abuse for the transactional mail.
One approach to convey this identifier is to encode this information
into the signing identity ("i=" value) in the signature. Since
[RFC4871] does not explicitly say that the signing identity is an
email address (although it specifies an email address-like syntax for
this value), either the local-part or the subdomain of the i= value
might be available to convey information to reputation systems.
However, this approach does not indicate the intent of the signer
Fenton Expires August 16, 2009 [Page 2]
Internet-Draft DKIM Reputation Hint February 2009
that these fields be used for accruing and looking up reputation
information, and conflicts with other uses for the signing identity
value, such as to denote an email address.
Use of the reputation tag defined herein is entirely at the
discretion of the verifier and any reputation algorithm or service
that may be associated with the receive-side processing of the
message. Verifiers MAY ignore the tag entirely or MAY use the
reputation tag value when provided by domains they judge to be
reliable.
In order to permit useful reputation accrual, the value of the
reputation tag will typically need to be stable over a relatively
long period of time. The use of a tag which is independent of other
identifiers (such as email address) supports this need by providing
continuity, even when other identifiers change.
1.1. Requirements Notation
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].
2. DKIM-Signature r= Tag Specification
In the ABNF below, the FWS token is inherited from [RFC5322] with the
exclusion of obs-FWS. The hyphenated-word token is inherited from
[RFC4871] and the overall ABNF syntax is from [RFC5234].
The following new tag/value pair is defined for the DKIM-Signature
header field:
r= Reputation hint (plain-text; OPTIONAL, default is null value).
This tag is a hint which MAY be used by verifiers and reputation
systems for classifying messages at a level of granularity finer
than that of the signing domain. The value of this tag is
significant only to the signer. Messages from the same signing
domain (d= value) with equal r= values MAY be considered together
when accruing and obtaining reputation information. The r= value
is significant only within a given signing domain; messages with
equal r= values but different d= values MUST NOT be considered
together unless information relating the domains is available
through a trusted out-of-band mechanism.
Fenton Expires August 16, 2009 [Page 3]
Internet-Draft DKIM Reputation Hint February 2009
ABNF:
sig-r-tag = %x72 [FWS] "=" [FWS] reputation-hint
reputation-hint = hyphenated-word
3. IANA Considerations
This document defines a new tag specification for the DKIM-Signature
header field, for which a registry is defined in [RFC4871] Section
7.1. Upon publication of this draft as an RFC, IANA is requested to
add an additional tag specificiation, "r", citing this document as a
reference.
4. Security Considerations
Like other information in DKIM-Signature header fields, the DKIM
reputation hint is an assertion on the part of the signer of the
message. Since bad actors as well as good actors are able to sign
messages with DKIM, it is important to consider how these tags might
be abused.
One thing a bad actor might seek to do is to diffuse an adverse
reputation by encouraging reputation maintainers to accrue reputation
on an extremely fine-grained basis. There is some evidence that bad
actors are already signing using domains registered for the purpose
of diffusing reputation; the r= value makes it potentially easier to
do that, since it can be changed without the overhead of registering
a new domain.
The best defense against this attack is to make use of the r= value
in conjunction with some other indication that the d= domain uses
this value with good intent. This other indication could be in the
form of an aggregate reputation for the signing domain as a whole, or
in the form of an accreditation or other reliable out-of-band
indication of the good intent of the signing domain's r= assertion.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
Fenton Expires August 16, 2009 [Page 4]
Internet-Draft DKIM Reputation Hint February 2009
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Author's Address
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5914
Email: fenton@cisco.com
URI:
Fenton Expires August 16, 2009 [Page 5]