draft-ietf-repute-model-00.txt   draft-ietf-repute-model-01.txt 
Network Working Group N. Borenstein REPUTE Working Group N. Borenstein
Internet-Draft Mimecast Internet-Draft Mimecast
Intended status: Informational M. Kucherawy Intended status: Informational M. Kucherawy
Expires: June 1, 2012 Cloudmark Expires: September 6, 2012 Cloudmark
November 29, 2011 A. Sullivan, Ed.
Dyn, Inc.
March 5, 2012
A Model for Reputation Interchange A Model for Reputation Reporting
draft-ietf-repute-model-00 draft-ietf-repute-model-01
Abstract Abstract
This document describes the general model underlying a set of This document describes a general architecture for a reputation-based
proposals for the exchange of reputation information on the Internet, service and a model for the exchange of reputation information on the
and provides a roadmap to the four additional documents that Internet. The document roughly follows the recommendations of
collectively define a reputation interchange protocol. It is RFC4101 for describing a protocol model.
intended roughly to follow the recommendations of RFC4101 for
describing a protocol model.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2012. This Internet-Draft will expire on September 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Series . . . . . . . . . . . . . . . . . . . . . . . . 4 2. High-Level Architecture . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 4 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 6
3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Information Represented in a Response Set . . . . . . . . . . . 6
4. Information Represented in the Protocol . . . . . . . . . . . . 5 5. Information Flow in the Protocol . . . . . . . . . . . . . . . 7
5. Information Flow in the Protocol . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8
7.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 6 7.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 8
7.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 9
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Traditionally, most Internet protocols have taken place between Traditionally Internet protocols have operated between
unauthenticated entities. For example, when an email message is unauthenticated entities. For example, an email message's author
submitted via [SMTP], the server typically trusts the self- field (From) [MAIL] can contain any display name or address and is
identification of the sender, and the sender trusts that the [DNS] not verified by the recipient or other agents along the delivery
has led it to the right server. Both kinds of trust are easily path. Similarly, a sending email server using [SMTP] trusts that the
betrayed, leading to spam, phishing, and a host of other ills. [DNS] has led it to the intended receiving server. Both kinds of
trust are easily betrayed, opening the door for spam, phishing, and a
host of other ills.
In recent years, stronger identity mechanisms have begun to see wider In recent years, stronger identity mechanisms have begun to see wider
deployment. For example, the [DKIM] protocol permits a much higher deployment. For example, the [DKIM] protocol permits associating a
level of trust in the identity of the sending domain of an email validated identifier to a message. While this is a major step
message. While this is a major step forward, by itself it does forward, it does not distinguish between identifiers owned by good
little to solve the problem of bad actors on the Internet. Even if actors versus bad. Even if it is possible to validate the domain
you can be sure a message comes from a domain called name in an author field, such as "@trustworthy.example.com," there is
"trustworthy.example.com," you don't really know whether or not that no basis for knowing whether it is associated with a good actor
domain is trustworthy. As a practical matter, the bad actors seem to worthy of trust. As a practical matter, both bad actors and good
have adopted DKIM even more rapidly than the good ones, in the hope adopt basic authentication mechanisms, like DKIM. In fact, bad
that some receiving domains will naively confuse a confirmation of actors tend to adopt them even more rapidly than the good actors do
identity with trustworthiness. assuming that some receivers will confuse identity authentication
with identity assessment. The first merely means that the name is
being used by its owner or their agent, while the latter makes a
statement about the quality of the owner.
The next step, which could usefully be undertaken only in the The added requirement -- which can usefully be undertaken only in the
presence of such stronger identity mechanisms, is to establish a presence of such stronger identity validation -- is for a mechanism
mechanism by which mutually trusted parties can exchange information by which mutually trusted parties can exchange assessment information
about other parties. Such information is known as reputation about other actors. A dictionary definition of "reputation" is "the
information. estimation in which a person or thing is held, especially by the
community or the public generally", this aggregation of individual
assessments is called reputation information.
While the need for reputation information has been most clear in the While the need for reputation information has been most clear in the
email world, where abuses are commonplace, it is easy to think of email world, where abuses are commonplace, other Internet services
additional uses for such information. It could also be useful in are coming under attack, indicating a similar need. A reputation
rating the security of web sites, the quality of service of an mechanism also could be useful in rating the security of web sites,
Internet Service Provider (ISP) or Application Service Provider the quality of service of an Internet Service Provider (ISP) or
(ASP), the customer satisfaction levels at e-commerce sites, and even Application Service Provider (ASP), the customer satisfaction levels
things unrelated to Internet protocols, such as rating plumbers, at e-commerce sites, and even things unrelated to Internet protocols,
hotels, or books. Just as human beings traditionally rely on the such as rating plumbers, hotels, or books. Just as human beings
recommendations of trusted parties in the physical world, so too they traditionally rely on the recommendations of trusted parties in the
can be expected to make use of such reputation information in a physical world, so too they can be expected to make use of such
variety of applications on the Internet. reputation information in a variety of applications on the Internet.
Accordingly, this protocol is designed to facilitate a wide range of A full trust architecture encompasses a range of actors and
reputation applications. However, not all such reputations will need activities, to enable an end-to-end service for creating and
to convey the same information. An overall reckoning of goodness consuming trust-related information. One component of that is a
versus badness can be defined generically, but specific applications query mechanism, to permit retrieval of reputation information that
are likely to want to describe reputations for multiple attributes; facilitates a wide range of reputation applications. However, not
an e-commerce site might be rated on price, speed of delivery, all such reputation services will need to convey the same
customer service, etc., and might receive very different ratings on information. Some need only produce a basic rating, while others
each. Therefore, this protocol defines a generic mechanism and basic need to provide underlying detail. This is akin to the difference
format for reputation information, while allowing extensions for each between check approval versus a credit report.
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, work covered by
the current effort defines a generic query mechanism and basic format
for reputation information, while allowing extensions for each
application. application.
Omitted from this specification is the way by which an agent that Omitted from this effort is the means by which an reputation-
wishes to report reputation information regarding something goes reporting agent goes about collecting such data and the mechanism for
about collecting such data. The protcol defined in this document and creating an evaluation. The mechanism defined here merely enables
its companion documents is merely about asking a question and getting asking a question and getting an answer; the remainder of an overall
an answer; the remainder of the overall service provided by such an service provided by such a reputation agent is specific to the
agent is specific to the implementation of that service and is out of implementation of that service and is out of scope here.
scope here.
2. Document Series 2. High-Level Architecture
This memo represents the base specification, introducing a series of A reputation mechanism functions as a component of a service, such as
others that define the overall service and introduce the initial depicted in Figure 1 of [RFC5863]:
exemplary applications. The series is as follows:
1. RFCxxxx: A Model for Reputation Interchange (this memo) +------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
2. RFCxxxx+1: Using the DNS for Reputation Interchange Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM'
3. RFCxxxx+2: Using UDP for Reputation Interchange Here, the reputation mechanism is shown only as a query by an
Identity Assessor, made to Assessment Databases.
4. RFCxxxx+3: Using the DNS for Reputation Interchange The current work attends specifically to the details of the query
mechanism. It defines:
5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange o Vocabulary for the current work and work of this type
6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation o The types and content of queries that can be supported
7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation o The extensible range of response information that can be provided
3. Terminology and Definitions o A query/response protocol
This section defines terms used in the rest of the document. o Query/response transport conventions
3.1. Keywords The current work targets an extremely simple query/response model
that can be carried over a variety of mechanisms, including the
Domain Name System. (Although not typically thought of as a
'transport', the DNS provides generic capabilities and can be modeled
as a mechanism for transporting queries and responses that have
nothing to do with addresses.) Each specification for Repute
transport is independent of any other specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +-----------+ Query +----------+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | +. . . . . . . . . . . . . .>| |
document are to be interpreted as described in [KEYWORDS]. | Client | | Server |
| <. . . . . . . . . . . . . . + |
+-----+-----+ Response +-------+--+
| ^ |
V | |
+------+----+ +-----------+ | | Response
| Transport |--------------->| Transport |--+ | Set
+-----------+ DNS +-----------+ |
TCP V
UDP +------------+
... | Reputation |
| Database |
+------------+
3.2. Vocabulary Figure 2: Basic Reputation Query Service
A "vocabulary" comprises those data that are returned in response to 3. Terminology and Definitions
a reputation query about a particular entity. The vocabulary is
specific to an application; the data returned in the evaluation of This section defines terms used in the rest of the document.
email senders would be different than the reputation data returned
3.1. Response Set
A "Response Set" comprises those data that are returned in response
to a reputation query about a particular entity. The types of data
are specific to an application; the data returned in the evaluation
of email senders would be different than the reputation data returned
about a movie or a baseball player. about a movie or a baseball player.
Vocabularies have symbolic names, and these have to be registered Response Sets have symbolic names, and these have to be registered
with IANA to prevent name collisions. The IANA registries are with IANA to prevent name collisions. The IANA registries are
created in a separate memo. created in a separate memo.
4. Information Represented in the Protocol 4. Information Represented in a Response Set
The basic information to be represented in the protocol is fairly The basic information to be represented in the protocol is fairly
simple, and MUST include: simple, and includes:
o the identity of the entity providing the reputation information; 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 identity of the entity being rated;
o the overall rating score for that entity;
o the overall rating score for that entity; and o the level of confidence in the accuracy of that rating; and
o the number of data points underlying that score. o the number of data points underlying that score.
Beyond this, arbitrary amounts of additional information might be Beyond this, arbitrary amounts of additional information might be
represented for specific applications of the protocol. Such provided for specific uses of the service. The entire collection of
information is called the "vocabulary" for that application. The such information is called the "Response Set" for that application.
general protocol defines a syntax for representing such vocabularies, The query/response protocol defines a syntax for representing such
but each application will define its own vocabulary. Thus, the basic Response Sets, but each application defines its own Set. Thus, the
information MUST also include: basic information also includes:
o the name of the application for which the reputation data is being o the name of the application for which the reputation data is being
expressed. expressed.
For example, a subsequent document will define the reputation For example, a separate specification is needed for a reputation
vocabulary for the application "email-sending-domain" which will be Response Set for an "email-sending-domain" to be used to combat spam
used to combat spam and other abuses of email. Additional documents and other abuses of email. Additional documents define a [MIME] type
define a [MIME] type for reputation data, and protocols for for reputation data, and protocols for exchanging such data.
exchanging such data.
5. Information Flow in the Protocol 5. Information Flow in the Protocol
The basic reputation data represented in the new [MIME] media type The basic Response Set could be wrapped into a new MIME media type
can be transported in any number of ways, like any MIME object. [MIME] or a DNS RR, and transported accordingly. It also can be the
However, it is anticipated that the typical use of the protocol will integral payload of a purpose-built protocol. For basic request/
be a simple request/response. One entity will ask a second entity response scenario, one entity (the Client) will ask a second entity
for reputation data about a third entity, and the second entity will (the Server) for reputation data about a third entity (the Target),
respond with that data. and the second entity will respond with that data.
It is anticipated that a few applications, at least including the An applications might benefit from an extremely lightweight
email-sending-domain application, will need a small, lightweight mechanism, supporting constrained queries and responses, while others
protocol for such queries and responses, while other applications might need to support larger and more complex responses.
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 6. IANA Considerations
This memo presents no actions for IANA, though later memos in this This memo presents no actions for IANA, though later memos in this
series are likely to do so. series are likely to do so.
7. Security Considerations 7. Security Considerations
This memo introduces an overall protocol model, but no implementation This memo introduces an overall protocol model, but no implementation
details. As such, the security considerations presented here are details. As such, the security considerations presented here are
very high-level. The detailed analyses of the various specific very high-level. The detailed analyses of the various specific
components of the protocol can be found in the subsequent documents components of the protocol can be found the documents that
enumerated in Section 2. instantiate this model.
7.1. Biased Reputation Agents 7.1. Biased Reputation Agents
As with [VBR], an agent seeking to make use of a reputation reporting As with [VBR], an agent seeking to make use of a reputation reporting
service is placing some trust that the service presents an unbiased service is placing some trust that the service presents an unbiased
"opinion" of the object about which reputation is being returned. "opinion" of the object about which reputation is being returned.
The result of trusting the data is, presumably, to guide action taken The result of trusting the data is, presumably, to guide action taken
by the reputation client. It follows, then, that bias in the by the reputation client. It follows, then, that bias in the
reputation service can adversely affect the client. Clients, reputation service can adversely affect the client. Clients,
therefore, should be aware of this possibility and the impact it therefore, need to be aware of this possibility and the impact it
might have. For example, a biased system returning reputation might have. For example, a biased system returning reputation
information about a DNS domain found in email messages could result information about a DNS domain found in email messages could result
in the admission of spam, phishing or malware through a mail gateway. in the admission of spam, phishing or malware through a mail gateway.
Clients might also seek to interact only with reputation services Clients might also seek to interact only with reputation services
that offer some level of transparency into the computation of the that offer some level of transparency into the computation of the
results they return. How this might be evaluated, however, is not results they return. How this might be evaluated, however, is not
specified here. specified here.
Similarly, a client placing trust in the results returned by such a Similarly, a client placing trust in the results returned by such a
service might suffer if the service itself is compromised, returning service might suffer if the service itself is compromised, returning
biased results under the control of an attacker without the knowledge biased results under the control of an attacker without the knowledge
of the agency providing reputation service. This might result from 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- 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 the-middle attack. Protocols, therefore, need to be designed so as
be as resilient against such attacks as possible. to be as resilient against such attacks as possible.
7.2. Malformed Messages 7.2. Malformed Messages
Both clients and servers of reputation systems need to be resistant Both clients and servers of reputation systems need to be resistant
to attacks that involve malformed messages, deliberate or otherwise. to attacks that involve malformed messages, deliberate or otherwise.
Failure to do so creates an opportunity for a denial-of-service. Failure to do so creates an opportunity for a denial-of-service.
8. Informative References 8. Informative References
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
skipping to change at page 7, line 28 skipping to change at page 9, line 9
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, May 2010.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
Reference", RFC 5518, April 2009. Reference", RFC 5518, April 2009.
Appendix A. Public Discussion Appendix A. Public Discussion
Public discussion of this suite of memos takes place on the Public discussion of this suite of memos takes place on the
domainrep@ietf.org mailing list. See domainrep@ietf.org mailing list. See
skipping to change at page 8, line 15 skipping to change at page 10, line 4
Authors' Addresses Authors' Addresses
Nathaniel Borenstein Nathaniel Borenstein
Mimecast Mimecast
203 Crescent St., Suite 303 203 Crescent St., Suite 303
Waltham, MA 02453 Waltham, MA 02453
USA USA
Phone: +1 781 996 5340 Phone: +1 781 996 5340
Email: nsb@guppylake.com Email: nsb@guppylake.com
Murray S. Kucherawy Murray S. Kucherawy
Cloudmark Cloudmark
128 King St., 2nd Floor 128 King St., 2nd Floor
San Francisco, CA 94107 San Francisco, CA 94107
USA USA
Phone: +1 415 946 3800 Phone: +1 415 946 3800
Email: msk@cloudmark.com Email: msk@cloudmark.com
Andrew Sullivan (editor)
Dyn, Inc.
150 Dow St.
Manchester, NH 03101
USA
Email: asullivan@dyn.com
 End of changes. 45 change blocks. 
130 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/