idnits 2.17.1 draft-ietf-repute-model-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 (November 29, 2011) is 4533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Informational M. Kucherawy 5 Expires: June 1, 2012 Cloudmark 6 November 29, 2011 8 A Model for Reputation Interchange 9 draft-ietf-repute-model-00 11 Abstract 13 This document describes the general model underlying a set of 14 proposals for the exchange of reputation information on the Internet, 15 and provides a roadmap to the four additional documents that 16 collectively define a reputation interchange protocol. It is 17 intended roughly to follow the recommendations of RFC4101 for 18 describing a protocol model. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 1, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Document Series . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 4 57 3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Information Represented in the Protocol . . . . . . . . . . . . 5 60 5. Information Flow in the Protocol . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 6 64 7.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 7 65 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Traditionally, most Internet protocols have taken place between 72 unauthenticated entities. For example, when an email message is 73 submitted via [SMTP], the server typically trusts the self- 74 identification of the sender, and the sender trusts that the [DNS] 75 has led it to the right server. Both kinds of trust are easily 76 betrayed, leading to spam, phishing, and a host of other ills. 78 In recent years, stronger identity mechanisms have begun to see wider 79 deployment. For example, the [DKIM] protocol permits a much higher 80 level of trust in the identity of the sending domain of an email 81 message. While this is a major step forward, by itself it does 82 little to solve the problem of bad actors on the Internet. Even if 83 you can be sure a message comes from a domain called 84 "trustworthy.example.com," you don't really know whether or not that 85 domain is trustworthy. As a practical matter, the bad actors seem to 86 have adopted DKIM even more rapidly than the good ones, in the hope 87 that some receiving domains will naively confuse a confirmation of 88 identity with trustworthiness. 90 The next step, which could usefully be undertaken only in the 91 presence of such stronger identity mechanisms, is to establish a 92 mechanism by which mutually trusted parties can exchange information 93 about other parties. Such information is known as reputation 94 information. 96 While the need for reputation information has been most clear in the 97 email world, where abuses are commonplace, it is easy to think of 98 additional uses for such information. It could also be useful in 99 rating the security of web sites, the quality of service of an 100 Internet Service Provider (ISP) or Application Service Provider 101 (ASP), the customer satisfaction levels at e-commerce sites, and even 102 things unrelated to Internet protocols, such as rating plumbers, 103 hotels, or books. Just as human beings traditionally rely on the 104 recommendations of trusted parties in the physical world, so too they 105 can be expected to make use of such reputation information in a 106 variety of applications on the Internet. 108 Accordingly, this protocol is designed to facilitate a wide range of 109 reputation applications. However, not all such reputations will need 110 to convey the same information. An overall reckoning of goodness 111 versus badness can be defined generically, but specific applications 112 are likely to want to describe reputations for multiple attributes; 113 an e-commerce site might be rated on price, speed of delivery, 114 customer service, etc., and might receive very different ratings on 115 each. Therefore, this protocol defines a generic mechanism and basic 116 format for reputation information, while allowing extensions for each 117 application. 119 Omitted from this specification is the way by which an agent that 120 wishes to report reputation information regarding something goes 121 about collecting such data. The protcol defined in this document and 122 its companion documents is merely about asking a question and getting 123 an answer; the remainder of the overall service provided by such an 124 agent is specific to the implementation of that service and is out of 125 scope here. 127 2. Document Series 129 This memo represents the base specification, introducing a series of 130 others that define the overall service and introduce the initial 131 exemplary applications. The series is as follows: 133 1. RFCxxxx: A Model for Reputation Interchange (this memo) 135 2. RFCxxxx+1: Using the DNS for Reputation Interchange 137 3. RFCxxxx+2: Using UDP for Reputation Interchange 139 4. RFCxxxx+3: Using the DNS for Reputation Interchange 141 5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange 143 6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation 145 7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation 147 3. Terminology and Definitions 149 This section defines terms used in the rest of the document. 151 3.1. Keywords 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [KEYWORDS]. 157 3.2. Vocabulary 159 A "vocabulary" comprises those data that are returned in response to 160 a reputation query about a particular entity. The vocabulary is 161 specific to an application; the data returned in the evaluation of 162 email senders would be different than the reputation data returned 163 about a movie or a baseball player. 165 Vocabularies have symbolic names, and these have to be registered 166 with IANA to prevent name collisions. The IANA registries are 167 created in a separate memo. 169 4. Information Represented in the Protocol 171 The basic information to be represented in the protocol is fairly 172 simple, and MUST include: 174 o the identity of the entity providing the reputation information; 176 o the level of confidence in that identity being genuine; 178 o the identity of the entity being rated; 180 o the overall rating score for that entity; and 182 o the number of data points underlying that score. 184 Beyond this, arbitrary amounts of additional information might be 185 represented for specific applications of the protocol. Such 186 information is called the "vocabulary" for that application. The 187 general protocol defines a syntax for representing such vocabularies, 188 but each application will define its own vocabulary. Thus, the basic 189 information MUST also include: 191 o the name of the application for which the reputation data is being 192 expressed. 194 For example, a subsequent document will define the reputation 195 vocabulary for the application "email-sending-domain" which will be 196 used to combat spam and other abuses of email. Additional documents 197 define a [MIME] type for reputation data, and protocols for 198 exchanging such data. 200 5. Information Flow in the Protocol 202 The basic reputation data represented in the new [MIME] media type 203 can be transported in any number of ways, like any MIME object. 204 However, it is anticipated that the typical use of the protocol will 205 be a simple request/response. One entity will ask a second entity 206 for reputation data about a third entity, and the second entity will 207 respond with that data. 209 It is anticipated that a few applications, at least including the 210 email-sending-domain application, will need a small, lightweight 211 protocol for such queries and responses, while other applications 212 will need to be able to retrieve larger and more complex responses. 213 For this reason, two subsequent documents define two such protocols, 214 one based on DNS queries and a terse representation, and one based on 215 [HTTP] queries with an XML representation. 217 6. IANA Considerations 219 This memo presents no actions for IANA, though later memos in this 220 series are likely to do so. 222 7. Security Considerations 224 This memo introduces an overall protocol model, but no implementation 225 details. As such, the security considerations presented here are 226 very high-level. The detailed analyses of the various specific 227 components of the protocol can be found in the subsequent documents 228 enumerated in Section 2. 230 7.1. Biased Reputation Agents 232 As with [VBR], an agent seeking to make use of a reputation reporting 233 service is placing some trust that the service presents an unbiased 234 "opinion" of the object about which reputation is being returned. 235 The result of trusting the data is, presumably, to guide action taken 236 by the reputation client. It follows, then, that bias in the 237 reputation service can adversely affect the client. Clients, 238 therefore, should be aware of this possibility and the impact it 239 might have. For example, a biased system returning reputation 240 information about a DNS domain found in email messages could result 241 in the admission of spam, phishing or malware through a mail gateway. 243 Clients might also seek to interact only with reputation services 244 that offer some level of transparency into the computation of the 245 results they return. How this might be evaluated, however, is not 246 specified here. 248 Similarly, a client placing trust in the results returned by such a 249 service might suffer if the service itself is compromised, returning 250 biased results under the control of an attacker without the knowledge 251 of the agency providing reputation service. This might result from 252 an attack on the data being returned at the source, or from a man-in- 253 the-middle attack. Protocols, therefore, should be designed so as to 254 be as resilient against such attacks as possible. 256 7.2. Malformed Messages 258 Both clients and servers of reputation systems need to be resistant 259 to attacks that involve malformed messages, deliberate or otherwise. 260 Failure to do so creates an opportunity for a denial-of-service. 262 8. Informative References 264 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 265 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 266 Signatures", RFC 4871, May 2007. 268 [DNS] Mockapetris, P., "Domain names - implementation and 269 specification", STD 13, RFC 1035, November 1987. 271 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 272 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 273 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 275 [KEYWORDS] 276 Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 280 Extensions (MIME) Part One: Format of Internet Message 281 Bodies", RFC 2045, November 1996. 283 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 284 October 2008. 286 [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 287 Reference", RFC 5518, April 2009. 289 Appendix A. Public Discussion 291 Public discussion of this suite of memos takes place on the 292 domainrep@ietf.org mailing list. See 293 https://www.ietf.org/mailman/listinfo/domainrep. 295 Authors' Addresses 297 Nathaniel Borenstein 298 Mimecast 299 203 Crescent St., Suite 303 300 Waltham, MA 02453 301 USA 303 Phone: +1 781 996 5340 304 Email: nsb@guppylake.com 306 Murray S. Kucherawy 307 Cloudmark 308 128 King St., 2nd Floor 309 San Francisco, CA 94107 310 USA 312 Phone: +1 415 946 3800 313 Email: msk@cloudmark.com