draft-ietf-repute-model-01.txt   draft-ietf-repute-model-02.txt 
REPUTE 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: September 6, 2012 Cloudmark Expires: December 17, 2012 Cloudmark
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
March 5, 2012 June 15, 2012
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-01 draft-ietf-repute-model-02
Abstract Abstract
This document describes a general architecture for a reputation-based This document describes a general architecture for a reputation-based
service and a model for the exchange of reputation information on the service and a model for the exchange of reputation information on the
Internet. The document roughly follows the recommendations of Internet. The document roughly follows the recommendations of
RFC4101 for describing a protocol model. RFC4101 for describing a protocol model.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 6, 2012. This Internet-Draft will expire on December 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. High-Level Architecture . . . . . . . . . . . . . . . . . . . . 4 2. High-Level Architecture . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 6 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 6
3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6
4. Information Represented in a Response Set . . . . . . . . . . . 6 4. Information Represented in a Response Set . . . . . . . . . . . 6
5. Information Flow in the Protocol . . . . . . . . . . . . . . . 7 5. Information Flow in the Protocol . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8
7.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 8 8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8 8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 9 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Traditionally Internet protocols have operated between Historically, many Internet protocols have operated between
unauthenticated entities. For example, an email message's author unauthenticated entities. For example, an email message's author
field (From) [MAIL] can contain any display name or address and is field (From) [MAIL] can contain any display name or address and is
not verified by the recipient or other agents along the delivery not verified by the recipient or other agents along the delivery
path. Similarly, a sending email server using [SMTP] trusts that the path. Similarly, a sending email server using [SMTP] trusts that the
[DNS] has led it to the intended receiving server. Both kinds of [DNS] has led it to the intended receiving server. Both kinds of
trust are easily betrayed, opening the door for spam, phishing, and a trust are easily betrayed, opening the operation to subversion of
host of other ills. some kind, which leads to spam, phishing, and other attacks.
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 associating a deployment. For example, the [DKIM] protocol permits associating a
validated identifier to a message. While this is a major step validated identifier to a message. This association is
forward, it does not distinguish between identifiers owned by good cryptographically strong, and is an improvement over the prior state
actors versus bad. Even if it is possible to validate the domain of affairs, but it does not distinguish between identifiers of good
name in an author field, such as "@trustworthy.example.com," there is actors and bad. Even when it is possible to validate the domain name
no basis for knowing whether it is associated with a good actor in an author field (e.g. "trustworthy.example.com" in
worthy of trust. As a practical matter, both bad actors and good "john.doe@trustworthy.example.com") there is no basis for knowing
adopt basic authentication mechanisms, like DKIM. In fact, bad whether it is associated with a good actor worthy of trust. As a
actors tend to adopt them even more rapidly than the good actors do practical matter, both bad actors and good adopt basic authentication
assuming that some receivers will confuse identity authentication mechanisms like DKIM. In fact, bad actors tend to adopt them even
with identity assessment. The first merely means that the name is more rapidly than the good actors do in the hope that some receivers
being used by its owner or their agent, while the latter makes a will confuse identity authentication with identity assessment. The
statement about the quality of the owner. former 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 added requirement -- which can usefully be undertaken only in the The added requirement -- which can usefully be undertaken only in the
presence of such stronger identity validation -- is for a mechanism presence of such stronger identity validation -- is for a mechanism
by which mutually trusted parties can exchange assessment information by which mutually trusted parties can exchange assessment information
about other actors. A dictionary definition of "reputation" is "the about other actors. For these purposes, we may usefully define
estimation in which a person or thing is held, especially by the "reputation" as "the estimation in which an identifiable actor is
community or the public generally", this aggregation of individual held, especially by the community or the Internet public generally".
assessments is called reputation information. We may call an aggregation of individual assessments "reputation
information."
While the need for reputation information has been most clear in the While the need for reputation information has been perhaps most clear
email world, where abuses are commonplace, other Internet services in the email world, where abuses are commonplace, other Internet
are coming under attack, indicating a similar need. A reputation services are coming under attack and may have a similar need. For
mechanism also could be useful in rating the security of web sites, instance, a reputation mechanism could be useful in rating the
the quality of service of an Internet Service Provider (ISP) or security of web sites; the quality of service of an Internet Service
Application Service Provider (ASP), the customer satisfaction levels Provider (ISP) or Application Service Provider (ASP); customer
at e-commerce sites, and even things unrelated to Internet protocols, satisfaction at e-commerce sites; and even things unrelated to
such as rating plumbers, hotels, or books. Just as human beings Internet protocols, such as plumbers, hotels, or books. Just as
traditionally rely on the recommendations of trusted parties in the human beings traditionally rely on the recommendations of trusted
physical world, so too they can be expected to make use of such parties in the physical world, so too they can be expected to make
reputation information in a variety of applications on the Internet. use of such reputation information in a variety of applications on
the Internet.
A full trust architecture encompasses a range of actors and A full trust architecture encompasses a range of actors and
activities, to enable an end-to-end service for creating and activities, to enable an end-to-end service for creating and
consuming trust-related information. One component of that is a consuming trust-related information. One component of that is a
query mechanism, to permit retrieval of reputation information that query mechanism, to permit retrieval of reputation information. Not
facilitates a wide range of reputation applications. However, not
all such reputation services will need to convey the same all such reputation services will need to convey the same
information. Some need only produce a basic rating, while others information. Some need only produce a basic rating, while others
need to provide underlying detail. This is akin to the difference need to provide underlying detail. This is akin to the difference
between check approval versus a credit report. between check approval versus a credit report.
An overall reckoning of goodness versus badness can be defined An overall reckoning of goodness versus badness can be defined
generically, but specific applications are likely to want to describe generically, but specific applications are likely to want to describe
reputations for multiple attributes; an e-commerce site might be reputations for multiple attributes: an e-commerce site might be
rated on price, speed of delivery, customer service, etc., and might rated on price, speed of delivery, customer service, etc., and might
receive very different ratings on each. Therefore, work covered by receive very different ratings on each. Therefore, a model defines a
the current effort defines a generic query mechanism and basic format generic query mechanism and basic format for reputation information,
for reputation information, while allowing extensions for each but allows extensions for each application.
application.
Omitted from this effort is the means by which an reputation- Omitted from this model is the means by which an reputation-reporting
reporting agent goes about collecting such data and the mechanism for agent goes about collecting such data and the mechanism for creating
creating an evaluation. The mechanism defined here merely enables an evaluation. The mechanism defined here merely enables asking a
asking a question and getting an answer; the remainder of an overall question and getting an answer; the remainder of an overall service
service provided by such a reputation agent is specific to the provided by such a reputation agent is specific to the implementation
implementation of that service and is out of scope here. of that service and is out of scope here.
2. High-Level Architecture 2. High-Level Architecture
A reputation mechanism functions as a component of a service, such as A reputation mechanism functions as a component of a service, such as
depicted in Figure 1 of [RFC5863]: that depicted in Figure 1 of [RFC5863], reproduced here:
+------+------+ +------+------+ +------+------+ +------+------+
| Author | | Recipient | | Author | | Recipient |
+------+------+ +------+------+ +------+------+ +------+------+
| ^ | ^
| | | |
| +------+------+ | +------+------+
| -->| Handling |<-- | -->| Handling |<--
| -->| Filter |<-- | -->| Filter |<--
| +-------------+ | +-------------+
skipping to change at page 5, line 35 skipping to change at page 5, line 35
| | Signer +------------->| Validator | | | Databases | | | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+ | +-------------+ +-------------+ | +-----------+
| DKIM Service | | DKIM Service |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM' Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM'
Here, the reputation mechanism is shown only as a query by an Here, the reputation mechanism is shown only as a query by an
Identity Assessor, made to Assessment Databases. Identity Assessor, made to Assessment Databases.
The current work attends specifically to the details of the query This memo outlines the query and response mechanism. It provides the
mechanism. It defines: following definitions:
o Vocabulary for the current work and work of this type o Vocabulary for the current work and work of this type;
o The types and content of queries that can be supported o The types and content of queries that can be supported;
o The extensible range of response information that can be provided o The extensible range of response information that can be provided;
o A query/response protocol o A query/response protocol;
o Query/response transport conventions o Query/response transport conventions.
The current work targets an extremely simple query/response model It provides an extremely simple query/response model that can be
that can be carried over a variety of mechanisms, including the carried over a variety of transports, including the Domain Name
Domain Name System. (Although not typically thought of as a System. (Although not typically thought of as a 'transport', the DNS
'transport', the DNS provides generic capabilities and can be modeled provides generic capabilities and can be thought of as a mechanism
as a mechanism for transporting queries and responses that have for transporting queries and responses that have nothing to do with
nothing to do with addresses.) Each specification for Repute addresses.) Each specification for Repute transport is independent
transport is independent of any other specification. of any other specification. A diagram of the basic query service is
found in Figure 2.
+-----------+ Query +----------+ +-----------+ Query +----------+
| +. . . . . . . . . . . . . .>| | | +. . . . . . . . . . . . . .>| |
| Client | | Server | | Client | | Server |
| <. . . . . . . . . . . . . . + | | <. . . . . . . . . . . . . . + |
+-----+-----+ Response +-------+--+ +-----+-----+ Response +-------+--+
| ^ | | ^ |
V | | V | |
+------+----+ +-----------+ | | Response +------+----+ +-----------+ | | Response
| Transport |--------------->| Transport |--+ | Set | Transport |--------------->| Transport |--+ | Set
+-----------+ DNS +-----------+ | +-----------+ DNS +-----------+ |
TCP V TCP V
UDP +------------+ UDP +------------+
... | Reputation | ... | Reputation |
| Database | | Database |
+------------+ +------------+
Figure 2: Basic Reputation Query Service Figure 2: Basic Reputation Query Service
Both the query and response are application-specific. An application
of the model defines the parameters available to queries of that
type, and also defines the data returned in response to any query.
3. Terminology and Definitions 3. Terminology and Definitions
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
3.1. Response Set 3.1. Response Set
A "Response Set" comprises those data that are returned in response A "Response Set" comprises those data that are returned in response
to a reputation query about a particular entity. The types of data to a reputation query about a particular entity. The types of data
are specific to an application; the data returned in the evaluation are specific to an application; the data returned in the evaluation
of email senders would be different than the reputation data returned 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.
Response Sets 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. IANA registries are created in
created in a separate memo. a separate memo. Each definition of a Response Set needs to define
its registry entry.
4. Information Represented in a Response Set 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 includes: simple, and includes the following:
o the identity of the entity providing the reputation information; o the identity of the entity providing the reputation information;
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;
o the level of confidence in the accuracy of that rating; 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
provided for specific uses of the service. The entire collection of provided for specific uses of the service. The entire collection is
such information is called the "Response Set" for that application. the Response Set for that application. The query/response protocol
The query/response protocol defines a syntax for representing such defines a syntax for representing such Response Sets, but each
Response Sets, but each application defines its own Set. Thus, the application defines its own Response Set. Thus, the basic information
basic information also includes: also includes the name of the application for which the reputation
data is being expressed.
o the name of the application for which the reputation data is being
expressed.
For example, a separate specification is needed for a reputation Each application requires its own specification of the Response Set.
Response Set for an "email-sending-domain" to be used to combat spam For example, a specification might be needed for a reputation
and other abuses of email. Additional documents define a [MIME] type Response Set for an "email-sending-domain"; the Response Set might
for reputation data, and protocols for exchanging such data. include information on how often spam was received from that domain.
Additional documents define a [MIME] type for reputation data, and
protocols for exchanging such data.
5. Information Flow in the Protocol 5. Information Flow in the Protocol
The basic Response Set could be wrapped into a new MIME media type The basic Response Set could be wrapped into a new MIME media type
[MIME] or a DNS RR, and transported accordingly. It also can be the [MIME] or a DNS RR, and transported accordingly. It also could be
integral payload of a purpose-built protocol. For basic request/ the integral payload of a purpose-built protocol. For a basic
response scenario, one entity (the Client) will ask a second entity request/response scenario, one entity (the Client) will ask a second
(the Server) for reputation data about a third entity (the Target), entity (the Server) for reputation data about a third entity (the
and the second entity will respond with that data. Target), and the second entity will respond with that data.
An applications might benefit from an extremely lightweight An applications might benefit from an extremely lightweight
mechanism, supporting constrained queries and responses, while others mechanism, supporting constrained queries and responses, while others
might need to support larger and more complex responses. might need to support larger and more complex responses.
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.
series are likely to do so.
7. Security Considerations 7. Privacy Considerations
Some kinds of reputation data are sensitive, and should not be shared
publicly. For applications that have such sensitivity, it is
imperative to pick a transport that will provide the required
authentication and authorization mechanisms in order to secure
communication and deliver responses correctly according to the
proferred credentials. Such transport questions are the province of
the application definitions.
8. 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 the documents that components of the protocol can be found the documents that
instantiate this model. instantiate this model.
7.1. Biased Reputation Agents 8.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, need to be aware of this possibility and the impact it therefore need to be aware of this possibility and the effect 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
(by rating the domain name more favourably than warranted) or could
Clients might also seek to interact only with reputation services result in the needless rejection or delay of mail (by rating the
that offer some level of transparency into the computation of the domain more unfavourably than warranted). As a possible mitigation
results they return. How this might be evaluated, however, is not strategy, clients might seek to interact only with reputation
specified here. services that offer some disclosure of the computation methods for
the results they return. Such disclosure and evaluation is beyond
the scope of the present memo.
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 the reputation service. This might result
an attack on the data being returned at the source, or from a man-in- from an attack on the data being returned at the source, or from a
the-middle attack. Protocols, therefore, need to be designed so as man-in-the-middle attack. Protocols, therefore, need to be designed
to be as resilient against such attacks as possible. so as to be as resilient against such attacks as possible.
7.2. Malformed Messages 8.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 9. Informative References
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. 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.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. 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, [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development, "DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, May 2010. Deployment, and Operations", RFC 5863, May 2010.
skipping to change at page 10, line 4 skipping to change at page 10, line 15
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 Email: superuser@gmail.com
Email: msk@cloudmark.com
Andrew Sullivan (editor) Andrew Sullivan (editor)
Dyn, Inc. Dyn, Inc.
150 Dow St. 150 Dow St.
Manchester, NH 03101 Manchester, NH 03101
USA USA
Email: asullivan@dyn.com Email: asullivan@dyn.com
 End of changes. 40 change blocks. 
114 lines changed or deleted 127 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/