idnits 2.17.1 draft-ietf-repute-model-04.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 28, 2013) is 4074 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 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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: September 1, 2013 Cloudmark 6 A. Sullivan, Ed. 7 Dyn, Inc. 8 February 28, 2013 10 A Model for Reputation Reporting 11 draft-ietf-repute-model-04 13 Abstract 15 This document describes a general architecture for a reputation-based 16 service and a model for requesting reputation-related data over the 17 Internet, where "reputation" refers to predictions or expectations 18 about an entity or an identifier such as a domain name. The document 19 roughly follows the recommendations of RFC4101 for describing a 20 protocol model. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 1, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. High-Level Architecture . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 59 3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Information Represented in a Response Set . . . . . . . . . . 6 61 5. Information Flow in the Reputation Query Protocol . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8 66 8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9 67 8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9 68 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 69 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Historically, many Internet protocols have operated between 75 unauthenticated entities. For example, an email message's author 76 field (From) [MAIL] can contain any display name or address and is 77 not verified by the recipient or other agents along the delivery 78 path. Similarly, a sending email server using [SMTP] trusts that the 79 [DNS] has led it to the intended receiving server. Both kinds of 80 trust are easily betrayed, opening the operation to subversion of 81 some kind, which leads to spam, phishing, and other attacks. 83 In recent years, explicit identity authentication mechanisms have 84 begun to see wider deployment. For example, the [DKIM] protocol 85 permits associating a validated identifier to a message. This 86 association is cryptographically strong, and is an improvement over 87 the prior state of affairs, but it does not distinguish between 88 identifiers of good actors and bad. Even when it is possible to 89 validate the domain name in an author field (e.g. 90 "trustworthy.example.com" in "john.doe@trustworthy.example.com") 91 there is no basis for knowing whether it is associated with a good 92 actor worthy of trust. As a practical matter, both bad actors and 93 good adopt basic authentication mechanisms like DKIM. In fact, bad 94 actors tend to adopt them even more rapidly than the good actors do 95 in the hope that some receivers will confuse identity authentication 96 with identity assessment. The former merely means that the name is 97 being used by its owner or their agent, while the latter makes a 98 statement about the quality of the owner. 100 With the advent of these authentication protocols, it is possible to 101 statisfy the requirement for a mechanism by which mutually trusted 102 parties can exchange assessment information about other actors. For 103 these purposes, we may usefully define "reputation" as "the 104 estimation in which an identifiable actor is held, especially by the 105 community or the Internet public generally". We may call an 106 aggregation of individual assessments "reputation input." 108 While the need for reputation services has been perhaps especially 109 clear in the email world, where abuses are commonplace, other 110 Internet services are coming under attack and may have a similar 111 need. For instance, a reputation mechanism could be useful in rating 112 the security of web sites, the quality of service of an Internet 113 Service Provider (ISP), or an Application Service Provider (ASP). 114 More generally, there are many different opportunities for use of 115 reputation services, such as customer satisfaction at e-commerce 116 sites, and even things unrelated to Internet protocols, such as 117 plumbers, hotels, or books. Just as human beings traditionally rely 118 on the recommendations of trusted parties in the physical world, so 119 too they can be expected to make use of such reputation services in a 120 variety of applications on the Internet. 122 A full trust architecture encompasses a range of actors and 123 activities, to enable an end-to-end service for creating, exchanging, 124 and consuming trust-related information. One component of that is a 125 query mechanism, to permit retrieval of a reputation. Not all such 126 reputation services will need to convey the same information. Some 127 need only produce a basic rating, while others need to provide 128 underlying detail. This is akin to the difference between check 129 approval versus a credit report. 131 An overall reckoning of goodness versus badness can be defined 132 generically, but specific applications are likely to want to describe 133 reputations for multiple attributes: an e-commerce site might be 134 rated on price, speed of delivery, customer service, etc., and might 135 receive very different ratings on each. Therefore, the model defines 136 a generic query mechanism and basic format for reputation retrieval, 137 but allows extensions for each application. 139 Omitted from this model is the means by which a reputation-reporting 140 agent goes about collecting such data and the method for creating an 141 evaluation. The mechanism defined here merely enables asking a 142 question and getting an answer; the remainder of an overall service 143 provided by such a reputation agent is specific to the implementation 144 of that service and is out of scope here. 146 2. High-Level Architecture 148 A reputation mechanism functions as a component of a service, such as 149 that depicted in Figure 1 of [RFC5863], reproduced here: 151 +------+------+ +------+------+ 152 | Author | | Recipient | 153 +------+------+ +------+------+ 154 | ^ 155 | | 156 | +------+------+ 157 | -->| Handling |<-- 158 | -->| Filter |<-- 159 | +-------------+ 160 | ^ 161 V Responsible | 162 +-------------+ Identifier +------+------+ 163 | Responsible |. . . . . . . . . . .>| Identity | 164 | Identity | . . | Assessor | 165 +------+------+ . . +-------------+ 166 | V . ^ ^ 167 V . . | | 168 +------------------.-------.------------------+ | | 169 | +------+------+ . . . > . +-------------+ | | | +------------+ 170 | | Identifier | | Identifier +-|-+ +-+ Assessment | 171 | | Signer +------------>| Validator | | | Databases | 172 | +-------------+ +-------------+ | +------------+ 173 | DKIM Service | 174 +---------------------------------------------+ 176 Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM' 178 Here, the reputation mechanism is shown only as a query by an 179 Identity Assessor, made to Assessment Databases. 181 This memo outlines the query and response mechanism. It provides the 182 following definitions: 184 o Vocabulary for the current work and work of this type; 186 o The types and content of queries that can be supported; 188 o The extensible range of response information that can be provided; 190 o A query/response protocol; 192 o Query/response transport conventions. 194 It provides an extremely simple query/response model that can be 195 carried over a variety of transports, including the Domain Name 196 System. (Although not typically thought of as a 'transport', the DNS 197 provides generic capabilities and can be thought of as a mechanism 198 for transporting queries and responses that have nothing to do with 199 addresses.) Each specification for Repute transport is independent 200 of any other specification. A diagram of the basic query service is 201 found in Figure 2. 203 +-----------+ Query +----------+ 204 | +. . . . . . . . . . . . . .>| | 205 | Client | | Server | 206 | <. . . . . . . . . . . . . . + | 207 +-----+-----+ Response +-------+--+ 208 | ^ | 209 V | | 210 +------+----+ +-----------+ | | Response 211 | Transport |--------------->| Transport |--+ | Set 212 +-----------+ DNS +-----------+ | 213 TCP V 214 UDP +------------+ 215 ... | Reputation | 216 | Database | 217 +------------+ 219 Figure 2: Basic Reputation Query Service 221 Both the query and response are application-specific. An application 222 of the model defines the parameters available to queries of that 223 type, and also defines the data returned in response to any query. 225 3. Terminology and Definitions 227 This section defines terms used in the rest of the document. 229 3.1. Response Set 231 A "Response Set" comprises those data that are returned in response 232 to a reputation query about a particular entity. The types of data 233 are specific to an application; the data returned in the evaluation 234 of email senders would be different than the reputation data returned 235 about a movie or a baseball player. 237 Response Sets have symbolic names, and these have to be registered 238 with IANA to prevent name collisions. IANA registries are created in 239 a separate memo. Each definition of a Response Set needs to define 240 its registry entry. 242 4. Information Represented in a Response Set 244 The basic information to be represented in the protocol is fairly 245 simple, and includes the following: 247 o the identity of the entity providing the reputation information; 249 o the identity of the entity being rated; 251 o the overall rating score for that entity; 253 o the level of confidence in the accuracy of that rating; and 255 o the number of data points underlying that score. 257 Beyond this, arbitrary amounts of additional information might be 258 provided for specific uses of the service. The entire collection is 259 the Response Set for that application. The query/response protocol 260 defines a syntax for representing such Response Sets, but each 261 application defines its own Response Set. Thus, the basic information 262 also includes the name of the application for which the reputation 263 data is being expressed. 265 Each application requires its own specification of the Response Set. 266 For example, a specification might be needed for a reputation 267 Response Set for an "email-sending-domain"; the Response Set might 268 include information on how often spam was received from that domain. 269 Additional documents define a [MIME] type for reputation data, and 270 protocols for exchanging such data. 272 5. Information Flow in the Reputation Query Protocol 274 The basic Response Set could be wrapped into a new MIME media type 275 [MIME] or a DNS RR, and transported accordingly. It also could be 276 the integral payload of a purpose-built protocol. For a basic 277 request/response scenario, one entity (the Client) will ask a second 278 entity (the Server) for reputation data about a third entity (the 279 Target), and the second entity will respond with that data. 281 An applications might benefit from an extremely lightweight 282 mechanism, supporting constrained queries and responses, while others 283 might need to support larger and more complex responses. 285 6. IANA Considerations 287 This memo presents no actions for IANA. 289 [RFC Editor: Please remove this section prior to publication.] 291 7. Privacy Considerations 293 Some kinds of reputation data are sensitive, and should not be shared 294 publicly. For cases that have such sensitivity, it is imperative to 295 protect the information from unauthorized access and viewing. The 296 model described here neither suggests nor precludes any particular 297 transport mechanism for the data. However, for the purpose of 298 illustration, a reputation service that operates over HTTP might 299 employ any of its well-known mechanisms to solve these problems, 300 which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and 301 S/MIME [SMIME]. 303 8. Security Considerations 305 This memo introduces an overall protocol model, but no implementation 306 details. As such, the security considerations presented here are 307 very high-level. The detailed analyses of the various specific 308 components of the protocol can be found the documents that 309 instantiate this model. 311 8.1. Biased Reputation Agents 313 As with [VBR], an agent seeking to make use of a reputation reporting 314 service is placing some trust that the service presents an unbiased 315 "opinion" of the object about which reputation is being returned. 316 The result of trusting the data is, presumably, to guide action taken 317 by the reputation client. It follows, then, that bias in the 318 reputation service can adversely affect the client. Clients 319 therefore need to be aware of this possibility and the effect it 320 might have. For example, a biased system returning a reputation 321 about a DNS domain found in email messages could result in the 322 admission of spam, phishing or malware through a mail gateway (by 323 rating the domain name more favourably than warranted) or could 324 result in the needless rejection or delay of mail (by rating the 325 domain more unfavourably than warranted). As a possible mitigation 326 strategy, clients might seek to interact only with reputation 327 services that offer some disclosure of the computation methods for 328 the results they return. Such disclosure and evaluation is beyond 329 the scope of the present memo. 331 Similarly, a client placing trust in the results returned by such a 332 service might suffer if the service itself is compromised, returning 333 biased results under the control of an attacker without the knowledge 334 of the agency providing the reputation service. This might result 335 from an attack on the data being returned at the source, or from a 336 man-in-the-middle attack. Protocols, therefore, need to be designed 337 so as to be as resilient against such attacks as possible. 339 8.2. Malformed Messages 341 Both clients and servers of reputation systems need to be resistant 342 to attacks that involve malformed messages, deliberate or otherwise. 343 Malformations can be used to confound clients and servers alike in 344 terms of identifying the party or parties responsible for the content 345 under evaluation. This can result in delivery of undesirable or even 346 dangerous content. 348 8.3. Further Discussion 350 Numerous other topics related to use and management of reputation 351 systems can be found in [I-D.REPUTE-CONSIDERATIONS]. 353 9. Informative References 355 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 356 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 357 Signatures", RFC 4871, May 2007. 359 [DNS] Mockapetris, P., "Domain names - implementation and 360 specification", STD 13, RFC 1035, November 1987. 362 [I-D.REPUTE-CONSIDERATIONS] 363 Kucherawy, M., "Operational Considerations Regarding 364 Reputation Services", draft-ietf-repute-considerations 365 (work in progress), November 2012. 367 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 368 October 2008. 370 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 371 Extensions (MIME) Part One: Format of Internet Message 372 Bodies", RFC 2045, November 1996. 374 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 375 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 377 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 378 "DomainKeys Identified Mail (DKIM) Development, 379 Deployment, and Operations", RFC 5863, May 2010. 381 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 382 Mail Extensions (S/MIME) Version 3.2: Message 383 Specification", RFC 5751, January 2010. 385 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 386 October 2008. 388 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 389 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 391 [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 392 Reference", RFC 5518, April 2009. 394 Appendix A. Public Discussion 396 Public discussion of this suite of memos takes place on the 397 domainrep@ietf.org mailing list. See 398 https://www.ietf.org/mailman/listinfo/domainrep. 400 Authors' Addresses 402 Nathaniel Borenstein 403 Mimecast 404 203 Crescent St., Suite 303 405 Waltham, MA 02453 406 USA 408 Phone: +1 781 996 5340 409 Email: nsb@guppylake.com 411 Murray S. Kucherawy 412 Cloudmark 413 128 King St., 2nd Floor 414 San Francisco, CA 94107 415 USA 417 Email: superuser@gmail.com 419 Andrew Sullivan (editor) 420 Dyn, Inc. 421 150 Dow St. 422 Manchester, NH 03101 423 USA 425 Email: asullivan@dyn.com