A Model for Reputation Interchange
draft-ietf-repute-model-00
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7070.
|
|
---|---|---|---|
Authors | Dr. Nathaniel S. Borenstein , Murray Kucherawy | ||
Last updated | 2011-12-16 (Latest revision 2011-11-29) | ||
Replaces | draft-kucherawy-reputation-model | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 7070 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Pete Resnick | ||
Send notices to | repute-chairs@tools.ietf.org, draft-ietf-repute-model@tools.ietf.org |
draft-ietf-repute-model-00
Network Working Group N. Borenstein Internet-Draft Mimecast Intended status: Informational M. Kucherawy Expires: June 1, 2012 Cloudmark November 29, 2011 A Model for Reputation Interchange draft-ietf-repute-model-00 Abstract This document describes the general model underlying a set of proposals for the exchange of reputation information on the Internet, and provides a roadmap to the four additional documents that collectively define a reputation interchange protocol. It is intended roughly to follow the recommendations of RFC4101 for describing a protocol model. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 1, 2012. Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Borenstein & Kucherawy Expires June 1, 2012 [Page 1] Internet-Draft Reputation Base November 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Series . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 4 3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Information Represented in the Protocol . . . . . . . . . . . . 5 5. Information Flow in the Protocol . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 6 7.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Borenstein & Kucherawy Expires June 1, 2012 [Page 2] Internet-Draft Reputation Base November 2011 1. Introduction Traditionally, most Internet protocols have taken place between unauthenticated entities. For example, when an email message is submitted via [SMTP], the server typically trusts the self- identification of the sender, and the sender trusts that the [DNS] has led it to the right server. Both kinds of trust are easily betrayed, leading to spam, phishing, and a host of other ills. In recent years, stronger identity mechanisms have begun to see wider deployment. For example, the [DKIM] protocol permits a much higher level of trust in the identity of the sending domain of an email message. While this is a major step forward, by itself it does little to solve the problem of bad actors on the Internet. Even if you can be sure a message comes from a domain called "trustworthy.example.com," you don't really know whether or not that domain is trustworthy. As a practical matter, the bad actors seem to have adopted DKIM even more rapidly than the good ones, in the hope that some receiving domains will naively confuse a confirmation of identity with trustworthiness. The next step, which could usefully be undertaken only in the presence of such stronger identity mechanisms, is to establish a mechanism by which mutually trusted parties can exchange information about other parties. Such information is known as reputation information. While the need for reputation information has been most clear in the email world, where abuses are commonplace, it is easy to think of additional uses for such information. It could also be useful in rating the security of web sites, the quality of service of an Internet Service Provider (ISP) or Application Service Provider (ASP), the customer satisfaction levels at e-commerce sites, and even things unrelated to Internet protocols, such as rating plumbers, hotels, or books. Just as human beings traditionally rely on the recommendations of trusted parties in the physical world, so too they can be expected to make use of such reputation information in a variety of applications on the Internet. Accordingly, this protocol is designed to facilitate a wide range of reputation applications. However, not all such reputations will need to convey the same information. An overall reckoning of goodness versus badness can be defined generically, but specific applications are likely to want to describe reputations for multiple attributes; an e-commerce site might be rated on price, speed of delivery, customer service, etc., and might receive very different ratings on each. Therefore, this protocol defines a generic mechanism and basic format for reputation information, while allowing extensions for each Borenstein & Kucherawy Expires June 1, 2012 [Page 3] Internet-Draft Reputation Base November 2011 application. Omitted from this specification is the way by which an agent that wishes to report reputation information regarding something goes about collecting such data. The protcol defined in this document and its companion documents is merely about asking a question and getting an answer; the remainder of the overall service provided by such an agent is specific to the implementation of that service and is out of scope here. 2. Document Series This memo represents the base specification, introducing a series of others that define the overall service and introduce the initial exemplary applications. The series is as follows: 1. RFCxxxx: A Model for Reputation Interchange (this memo) 2. RFCxxxx+1: Using the DNS for Reputation Interchange 3. RFCxxxx+2: Using UDP for Reputation Interchange 4. RFCxxxx+3: Using the DNS for Reputation Interchange 5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange 6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation 7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation 3. Terminology and Definitions This section defines terms used in the rest of the document. 3.1. Keywords 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 [KEYWORDS]. 3.2. Vocabulary A "vocabulary" comprises those data that are returned in response to a reputation query about a particular entity. The vocabulary is specific to an application; the data returned in the evaluation of email senders would be different than the reputation data returned Borenstein & Kucherawy Expires June 1, 2012 [Page 4] Internet-Draft Reputation Base November 2011 about a movie or a baseball player. Vocabularies have symbolic names, and these have to be registered with IANA to prevent name collisions. The IANA registries are created in a separate memo. 4. Information Represented in the Protocol The basic information to be represented in the protocol is fairly simple, and MUST include: o the identity of the entity providing the reputation information; o the level of confidence in that identity being genuine; o the identity of the entity being rated; o the overall rating score for that entity; and o the number of data points underlying that score. Beyond this, arbitrary amounts of additional information might be represented for specific applications of the protocol. Such information is called the "vocabulary" for that application. The general protocol defines a syntax for representing such vocabularies, but each application will define its own vocabulary. Thus, the basic information MUST also include: o the name of the application for which the reputation data is being expressed. For example, a subsequent document will define the reputation vocabulary for the application "email-sending-domain" which will be used to combat spam and other abuses of email. Additional documents define a [MIME] type for reputation data, and protocols for exchanging such data. 5. Information Flow in the Protocol The basic reputation data represented in the new [MIME] media type can be transported in any number of ways, like any MIME object. However, it is anticipated that the typical use of the protocol will be a simple request/response. One entity will ask a second entity for reputation data about a third entity, and the second entity will respond with that data. Borenstein & Kucherawy Expires June 1, 2012 [Page 5] Internet-Draft Reputation Base November 2011 It is anticipated that a few applications, at least including the email-sending-domain application, will need a small, lightweight protocol for such queries and responses, while other applications will need to be able to retrieve larger and more complex responses. For this reason, two subsequent documents define two such protocols, one based on DNS queries and a terse representation, and one based on [HTTP] queries with an XML representation. 6. IANA Considerations This memo presents no actions for IANA, though later memos in this series are likely to do so. 7. Security Considerations This memo introduces an overall protocol model, but no implementation details. As such, the security considerations presented here are very high-level. The detailed analyses of the various specific components of the protocol can be found in the subsequent documents enumerated in Section 2. 7.1. Biased Reputation Agents As with [VBR], an agent seeking to make use of a reputation reporting service is placing some trust that the service presents an unbiased "opinion" of the object about which reputation is being returned. The result of trusting the data is, presumably, to guide action taken by the reputation client. It follows, then, that bias in the reputation service can adversely affect the client. Clients, therefore, should be aware of this possibility and the impact it might have. For example, a biased system returning reputation information about a DNS domain found in email messages could result in the admission of spam, phishing or malware through a mail gateway. Clients might also seek to interact only with reputation services that offer some level of transparency into the computation of the results they return. How this might be evaluated, however, is not specified here. Similarly, a client placing trust in the results returned by such a service might suffer if the service itself is compromised, returning biased results under the control of an attacker without the knowledge of the agency providing reputation service. This might result from an attack on the data being returned at the source, or from a man-in- the-middle attack. Protocols, therefore, should be designed so as to be as resilient against such attacks as possible. Borenstein & Kucherawy Expires June 1, 2012 [Page 6] Internet-Draft Reputation Base November 2011 7.2. Malformed Messages Both clients and servers of reputation systems need to be resistant to attacks that involve malformed messages, deliberate or otherwise. Failure to do so creates an opportunity for a denial-of-service. 8. Informative References [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009. Appendix A. Public Discussion Public discussion of this suite of memos takes place on the domainrep@ietf.org mailing list. See https://www.ietf.org/mailman/listinfo/domainrep. Borenstein & Kucherawy Expires June 1, 2012 [Page 7] Internet-Draft Reputation Base November 2011 Authors' Addresses Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA Phone: +1 781 996 5340 Email: nsb@guppylake.com Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA Phone: +1 415 946 3800 Email: msk@cloudmark.com Borenstein & Kucherawy Expires June 1, 2012 [Page 8]