idnits 2.17.00 (12 Aug 2021) /tmp/idnits15172/draft-fenton-dkim-reputation-hint-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2009) is 4839 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Fenton 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental February 12, 2009 5 Expires: August 16, 2009 7 DKIM Reputation Hint Extension 8 draft-fenton-dkim-reputation-hint-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 16, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document defines an extension to the DomainKeys Identified Mail 48 (DKIM) specification to provide an identifier that may be used as a 49 "hint" by reputation services using DKIM wanting to maintain 50 reputation information at a finer level of granularity than that of 51 the signing domain itself. 53 1. Introduction 55 DomainKeys Identified Mail (DKIM) [RFC4871] defines a simple, low 56 cost, and effective mechanism by which email messages can be 57 cryptographically signed, permitting a signing domain to claim 58 responsibility for the use of a given email address. Message 59 recipients can verify the signature by querying the signer's domain 60 directly to retrieve the appropriate public key, and thereby confirm 61 that the message was attested to by a party in possession of the 62 private key for the signing domain. 64 A frequently cited use for email authentication is that it provides a 65 basis for associating a reputation with the entity claiming 66 responsibility for the message. One way to do this is to associate 67 the reputation with the signing domain itself (the d= value in the 68 DKIM-Signature header field). However, many have expressed the 69 desire to provide more fine-grained information to aid reputation 70 maintainers and users in classifying their mail in a more detailed 71 manner. 73 Several use cases have been proposed for identifiers of this sort: 75 o A domain that supports multiple email addresses (personas) per 76 user may want to apply the same label to all messages from that 77 user so that an aggregate reputation of all of that user's 78 messages may accrue. 80 o A domain with a mixture of premium accounts (for which they 81 charge) and free accounts may want to label mail from those 82 accounts differently because of the higher potential for abuse of 83 the free accounts. 85 o A domain with a mixture of transactional and other mail may decide 86 to label the transactional mail separately from the other mail 87 because of the low potential of abuse for the transactional mail. 89 One approach to convey this identifier is to encode this information 90 into the signing identity ("i=" value) in the signature. Since 91 [RFC4871] does not explicitly say that the signing identity is an 92 email address (although it specifies an email address-like syntax for 93 this value), either the local-part or the subdomain of the i= value 94 might be available to convey information to reputation systems. 95 However, this approach does not indicate the intent of the signer 96 that these fields be used for accruing and looking up reputation 97 information, and conflicts with other uses for the signing identity 98 value, such as to denote an email address. 100 Use of the reputation tag defined herein is entirely at the 101 discretion of the verifier and any reputation algorithm or service 102 that may be associated with the receive-side processing of the 103 message. Verifiers MAY ignore the tag entirely or MAY use the 104 reputation tag value when provided by domains they judge to be 105 reliable. 107 In order to permit useful reputation accrual, the value of the 108 reputation tag will typically need to be stable over a relatively 109 long period of time. The use of a tag which is independent of other 110 identifiers (such as email address) supports this need by providing 111 continuity, even when other identifiers change. 113 1.1. Requirements Notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. DKIM-Signature r= Tag Specification 121 In the ABNF below, the FWS token is inherited from [RFC5322] with the 122 exclusion of obs-FWS. The hyphenated-word token is inherited from 123 [RFC4871] and the overall ABNF syntax is from [RFC5234]. 125 The following new tag/value pair is defined for the DKIM-Signature 126 header field: 128 r= Reputation hint (plain-text; OPTIONAL, default is null value). 129 This tag is a hint which MAY be used by verifiers and reputation 130 systems for classifying messages at a level of granularity finer 131 than that of the signing domain. The value of this tag is 132 significant only to the signer. Messages from the same signing 133 domain (d= value) with equal r= values MAY be considered together 134 when accruing and obtaining reputation information. The r= value 135 is significant only within a given signing domain; messages with 136 equal r= values but different d= values MUST NOT be considered 137 together unless information relating the domains is available 138 through a trusted out-of-band mechanism. 140 ABNF: 142 sig-r-tag = %x72 [FWS] "=" [FWS] reputation-hint 143 reputation-hint = hyphenated-word 145 3. IANA Considerations 147 This document defines a new tag specification for the DKIM-Signature 148 header field, for which a registry is defined in [RFC4871] Section 149 7.1. Upon publication of this draft as an RFC, IANA is requested to 150 add an additional tag specificiation, "r", citing this document as a 151 reference. 153 4. Security Considerations 155 Like other information in DKIM-Signature header fields, the DKIM 156 reputation hint is an assertion on the part of the signer of the 157 message. Since bad actors as well as good actors are able to sign 158 messages with DKIM, it is important to consider how these tags might 159 be abused. 161 One thing a bad actor might seek to do is to diffuse an adverse 162 reputation by encouraging reputation maintainers to accrue reputation 163 on an extremely fine-grained basis. There is some evidence that bad 164 actors are already signing using domains registered for the purpose 165 of diffusing reputation; the r= value makes it potentially easier to 166 do that, since it can be changed without the overhead of registering 167 a new domain. 169 The best defense against this attack is to make use of the r= value 170 in conjunction with some other indication that the d= domain uses 171 this value with good intent. This other indication could be in the 172 form of an aggregate reputation for the signing domain as a whole, or 173 in the form of an accreditation or other reliable out-of-band 174 indication of the good intent of the signing domain's r= assertion. 176 5. Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 182 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 183 Signatures", RFC 4871, May 2007. 185 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 186 Specifications: ABNF", STD 68, RFC 5234, January 2008. 188 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 189 October 2008. 191 Author's Address 193 Jim Fenton 194 Cisco Systems, Inc. 195 MS SJ-9/2 196 170 W. Tasman Drive 197 San Jose, CA 95134-1706 198 USA 200 Phone: +1 408 526 5914 201 Email: fenton@cisco.com 202 URI: