idnits 2.17.1 draft-ietf-repute-model-03.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 13, 2012) is 4174 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REPUTE Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Informational M. Kucherawy 5 Expires: May 17, 2013 Cloudmark 6 A. Sullivan, Ed. 7 Dyn, Inc. 8 November 13, 2012 10 A Model for Reputation Reporting 11 draft-ietf-repute-model-03 13 Abstract 15 This document describes a general architecture for a reputation-based 16 service and a model for the exchange of reputation information on the 17 Internet. The document roughly follows the recommendations of 18 RFC4101 for 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 May 17, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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. High-Level Architecture . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 57 3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Information Represented in a Response Set . . . . . . . . . . 6 59 5. Information Flow in the Protocol . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8 64 8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9 65 8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9 66 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 Historically, many Internet protocols have operated between 73 unauthenticated entities. For example, an email message's author 74 field (From) [MAIL] can contain any display name or address and is 75 not verified by the recipient or other agents along the delivery 76 path. Similarly, a sending email server using [SMTP] trusts that the 77 [DNS] has led it to the intended receiving server. Both kinds of 78 trust are easily betrayed, opening the operation to subversion of 79 some kind, which leads to spam, phishing, and other attacks. 81 In recent years, stronger identity mechanisms have begun to see wider 82 deployment. For example, the [DKIM] protocol permits associating a 83 validated identifier to a message. This association is 84 cryptographically strong, and is an improvement over the prior state 85 of affairs, but it does not distinguish between identifiers of good 86 actors and bad. Even when it is possible to validate the domain name 87 in an author field (e.g. "trustworthy.example.com" in 88 "john.doe@trustworthy.example.com") there is no basis for knowing 89 whether it is associated with a good actor worthy of trust. As a 90 practical matter, both bad actors and good adopt basic authentication 91 mechanisms like DKIM. In fact, bad actors tend to adopt them even 92 more rapidly than the good actors do in the hope that some receivers 93 will confuse identity authentication with identity assessment. The 94 former merely means that the name is being used by its owner or their 95 agent, while the latter makes a statement about the quality of the 96 owner. 98 The added requirement -- which can usefully be undertaken only in the 99 presence of such stronger identity validation -- is for a mechanism 100 by which mutually trusted parties can exchange assessment information 101 about other actors. For these purposes, we may usefully define 102 "reputation" as "the estimation in which an identifiable actor is 103 held, especially by the community or the Internet public generally". 104 We may call an aggregation of individual assessments "reputation 105 information." 107 While the need for reputation information has been perhaps most clear 108 in the email world, where abuses are commonplace, other Internet 109 services are coming under attack and may have a similar need. For 110 instance, a reputation mechanism could be useful in rating the 111 security of web sites; the quality of service of an Internet Service 112 Provider (ISP) or Application Service Provider (ASP); customer 113 satisfaction at e-commerce sites; and even things unrelated to 114 Internet protocols, such as plumbers, hotels, or books. Just as 115 human beings traditionally rely on the recommendations of trusted 116 parties in the physical world, so too they can be expected to make 117 use of such reputation information in a variety of applications on 118 the Internet. 120 A full trust architecture encompasses a range of actors and 121 activities, to enable an end-to-end service for creating and 122 consuming trust-related information. One component of that is a 123 query mechanism, to permit retrieval of reputation information. Not 124 all such reputation services will need to convey the same 125 information. Some need only produce a basic rating, while others 126 need to provide underlying detail. This is akin to the difference 127 between check approval versus a credit report. 129 An overall reckoning of goodness versus badness can be defined 130 generically, but specific applications are likely to want to describe 131 reputations for multiple attributes: an e-commerce site might be 132 rated on price, speed of delivery, customer service, etc., and might 133 receive very different ratings on each. Therefore, a model defines a 134 generic query mechanism and basic format for reputation information, 135 but allows extensions for each application. 137 Omitted from this model is the means by which an reputation-reporting 138 agent goes about collecting such data and the mechanism for creating 139 an evaluation. The mechanism defined here merely enables asking a 140 question and getting an answer; the remainder of an overall service 141 provided by such a reputation agent is specific to the implementation 142 of that service and is out of scope here. 144 2. High-Level Architecture 146 A reputation mechanism functions as a component of a service, such as 147 that depicted in Figure 1 of [RFC5863], reproduced here: 149 +------+------+ +------+------+ 150 | Author | | Recipient | 151 +------+------+ +------+------+ 152 | ^ 153 | | 154 | +------+------+ 155 | -->| Handling |<-- 156 | -->| Filter |<-- 157 | +-------------+ 158 | ^ 159 V Responsible | 160 +-------------+ Identifier +------+------+ 161 | Responsible |. . . . . . . . . . .>| Identity | 162 | Identity | . . | Assessor | 163 +------+------+ . . +-------------+ 164 | V . ^ ^ 165 V . . | | 166 +------------------.-------.------------------+ | | 167 | +------+------+ . . . > . +-------------+ | | | +------------+ 168 | | Identifier | | Identifier +-|-+ +-+ Assessment | 169 | | Signer +------------>| Validator | | | Databases | 170 | +-------------+ +-------------+ | +------------+ 171 | DKIM Service | 172 +---------------------------------------------+ 174 Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM' 176 Here, the reputation mechanism is shown only as a query by an 177 Identity Assessor, made to Assessment Databases. 179 This memo outlines the query and response mechanism. It provides the 180 following definitions: 182 o Vocabulary for the current work and work of this type; 184 o The types and content of queries that can be supported; 186 o The extensible range of response information that can be provided; 188 o A query/response protocol; 190 o Query/response transport conventions. 192 It provides an extremely simple query/response model that can be 193 carried over a variety of transports, including the Domain Name 194 System. (Although not typically thought of as a 'transport', the DNS 195 provides generic capabilities and can be thought of as a mechanism 196 for transporting queries and responses that have nothing to do with 197 addresses.) Each specification for Repute transport is independent 198 of any other specification. A diagram of the basic query service is 199 found in Figure 2. 201 +-----------+ Query +----------+ 202 | +. . . . . . . . . . . . . .>| | 203 | Client | | Server | 204 | <. . . . . . . . . . . . . . + | 205 +-----+-----+ Response +-------+--+ 206 | ^ | 207 V | | 208 +------+----+ +-----------+ | | Response 209 | Transport |--------------->| Transport |--+ | Set 210 +-----------+ DNS +-----------+ | 211 TCP V 212 UDP +------------+ 213 ... | Reputation | 214 | Database | 215 +------------+ 217 Figure 2: Basic Reputation Query Service 219 Both the query and response are application-specific. An application 220 of the model defines the parameters available to queries of that 221 type, and also defines the data returned in response to any query. 223 3. Terminology and Definitions 225 This section defines terms used in the rest of the document. 227 3.1. Response Set 229 A "Response Set" comprises those data that are returned in response 230 to a reputation query about a particular entity. The types of data 231 are specific to an application; the data returned in the evaluation 232 of email senders would be different than the reputation data returned 233 about a movie or a baseball player. 235 Response Sets have symbolic names, and these have to be registered 236 with IANA to prevent name collisions. IANA registries are created in 237 a separate memo. Each definition of a Response Set needs to define 238 its registry entry. 240 4. Information Represented in a Response Set 242 The basic information to be represented in the protocol is fairly 243 simple, and includes the following: 245 o the identity of the entity providing the reputation information; 247 o the identity of the entity being rated; 249 o the overall rating score for that entity; 251 o the level of confidence in the accuracy of that rating; and 253 o the number of data points underlying that score. 255 Beyond this, arbitrary amounts of additional information might be 256 provided for specific uses of the service. The entire collection is 257 the Response Set for that application. The query/response protocol 258 defines a syntax for representing such Response Sets, but each 259 application defines its own Response Set. Thus, the basic information 260 also includes the name of the application for which the reputation 261 data is being expressed. 263 Each application requires its own specification of the Response Set. 264 For example, a specification might be needed for a reputation 265 Response Set for an "email-sending-domain"; the Response Set might 266 include information on how often spam was received from that domain. 267 Additional documents define a [MIME] type for reputation data, and 268 protocols for exchanging such data. 270 5. Information Flow in the Protocol 272 The basic Response Set could be wrapped into a new MIME media type 273 [MIME] or a DNS RR, and transported accordingly. It also could be 274 the integral payload of a purpose-built protocol. For a basic 275 request/response scenario, one entity (the Client) will ask a second 276 entity (the Server) for reputation data about a third entity (the 277 Target), and the second entity will respond with that data. 279 An applications might benefit from an extremely lightweight 280 mechanism, supporting constrained queries and responses, while others 281 might need to support larger and more complex responses. 283 6. IANA Considerations 285 This memo presents no actions for IANA. 287 7. Privacy Considerations 289 Some kinds of reputation data are sensitive, and should not be shared 290 publicly. For applications that have such sensitivity, it is 291 imperative to pick a transport that will provide the required 292 authentication and authorization mechanisms in order to secure 293 communication and deliver responses correctly according to the 294 proferred credentials. Such transport questions are the province of 295 the application definitions. 297 8. Security Considerations 299 This memo introduces an overall protocol model, but no implementation 300 details. As such, the security considerations presented here are 301 very high-level. The detailed analyses of the various specific 302 components of the protocol can be found the documents that 303 instantiate this model. 305 8.1. Biased Reputation Agents 307 As with [VBR], an agent seeking to make use of a reputation reporting 308 service is placing some trust that the service presents an unbiased 309 "opinion" of the object about which reputation is being returned. 310 The result of trusting the data is, presumably, to guide action taken 311 by the reputation client. It follows, then, that bias in the 312 reputation service can adversely affect the client. Clients 313 therefore need to be aware of this possibility and the effect it 314 might have. For example, a biased system returning reputation 315 information about a DNS domain found in email messages could result 316 in the admission of spam, phishing or malware through a mail gateway 317 (by rating the domain name more favourably than warranted) or could 318 result in the needless rejection or delay of mail (by rating the 319 domain more unfavourably than warranted). As a possible mitigation 320 strategy, clients might seek to interact only with reputation 321 services that offer some disclosure of the computation methods for 322 the results they return. Such disclosure and evaluation is beyond 323 the scope of the present memo. 325 Similarly, a client placing trust in the results returned by such a 326 service might suffer if the service itself is compromised, returning 327 biased results under the control of an attacker without the knowledge 328 of the agency providing the reputation service. This might result 329 from an attack on the data being returned at the source, or from a 330 man-in-the-middle attack. Protocols, therefore, need to be designed 331 so as to be as resilient against such attacks as possible. 333 8.2. Malformed Messages 335 Both clients and servers of reputation systems need to be resistant 336 to attacks that involve malformed messages, deliberate or otherwise. 337 Malformations can be used to confound clients and servers alike in 338 terms of identifying the party or parties responsible for the content 339 under evaluation. This can result in delivery of undesirable or even 340 dangerous content. 342 8.3. Further Discussion 344 Numerous other topics related to use and management of reputation 345 systems can be found in [I-D.REPUTE-CONSIDERATIONS]. 347 9. Informative References 349 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 350 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 351 Signatures", RFC 4871, May 2007. 353 [DNS] Mockapetris, P., "Domain names - implementation and 354 specification", STD 13, RFC 1035, November 1987. 356 [I-D.REPUTE-CONSIDERATIONS] 357 Kucherawy, M., "Operational Considerations Regarding 358 Reputation Services", draft-ietf-repute-considerations 359 (work in progress), November 2012. 361 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 362 October 2008. 364 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 365 Extensions (MIME) Part One: Format of Internet Message 366 Bodies", RFC 2045, November 1996. 368 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 369 "DomainKeys Identified Mail (DKIM) Development, 370 Deployment, and Operations", RFC 5863, May 2010. 372 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 373 October 2008. 375 [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 376 Reference", RFC 5518, April 2009. 378 Appendix A. Public Discussion 380 Public discussion of this suite of memos takes place on the 381 domainrep@ietf.org mailing list. See 382 https://www.ietf.org/mailman/listinfo/domainrep. 384 Authors' Addresses 386 Nathaniel Borenstein 387 Mimecast 388 203 Crescent St., Suite 303 389 Waltham, MA 02453 390 USA 392 Phone: +1 781 996 5340 393 Email: nsb@guppylake.com 395 Murray S. Kucherawy 396 Cloudmark 397 128 King St., 2nd Floor 398 San Francisco, CA 94107 399 USA 401 Email: superuser@gmail.com 403 Andrew Sullivan (editor) 404 Dyn, Inc. 405 150 Dow St. 406 Manchester, NH 03101 407 USA 409 Email: asullivan@dyn.com