draft-ietf-repute-model-03.txt   draft-ietf-repute-model-04.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: May 17, 2013 Cloudmark Expires: September 1, 2013 Cloudmark
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
November 13, 2012 February 28, 2013
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-03 draft-ietf-repute-model-04
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 requesting reputation-related data over the
Internet. The document roughly follows the recommendations of Internet, where "reputation" refers to predictions or expectations
RFC4101 for describing a protocol model. about an entity or an identifier such as a domain name. The document
roughly follows 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 May 17, 2013. This Internet-Draft will expire on September 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. 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 Reputation Query Protocol . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8 8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8
8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9 8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9
8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9 8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 16 skipping to change at page 3, line 16
Historically, many 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 operation to subversion of trust are easily betrayed, opening the operation to subversion of
some kind, which leads to spam, phishing, and other attacks. some kind, which leads to spam, phishing, and other attacks.
In recent years, stronger identity mechanisms have begun to see wider In recent years, explicit identity authentication mechanisms have
deployment. For example, the [DKIM] protocol permits associating a begun to see wider deployment. For example, the [DKIM] protocol
validated identifier to a message. This association is permits associating a validated identifier to a message. This
cryptographically strong, and is an improvement over the prior state association is cryptographically strong, and is an improvement over
of affairs, but it does not distinguish between identifiers of good the prior state of affairs, but it does not distinguish between
actors and bad. Even when it is possible to validate the domain name identifiers of good actors and bad. Even when it is possible to
in an author field (e.g. "trustworthy.example.com" in validate the domain name in an author field (e.g.
"john.doe@trustworthy.example.com") there is no basis for knowing "trustworthy.example.com" in "john.doe@trustworthy.example.com")
whether it is associated with a good actor worthy of trust. As a there is no basis for knowing whether it is associated with a good
practical matter, both bad actors and good adopt basic authentication actor worthy of trust. As a practical matter, both bad actors and
mechanisms like DKIM. In fact, bad actors tend to adopt them even good adopt basic authentication mechanisms like DKIM. In fact, bad
more rapidly than the good actors do in the hope that some receivers actors tend to adopt them even more rapidly than the good actors do
will confuse identity authentication with identity assessment. The in the hope that some receivers will confuse identity authentication
former merely means that the name is being used by its owner or their with identity assessment. The former merely means that the name is
agent, while the latter makes a statement about the quality of the being used by its owner or their agent, while the latter makes a
owner. statement about the quality of the owner.
The added requirement -- which can usefully be undertaken only in the With the advent of these authentication protocols, it is possible to
presence of such stronger identity validation -- is for a mechanism statisfy the requirement for a mechanism by which mutually trusted
by which mutually trusted parties can exchange assessment information parties can exchange assessment information about other actors. For
about other actors. For these purposes, we may usefully define these purposes, we may usefully define "reputation" as "the
"reputation" as "the estimation in which an identifiable actor is estimation in which an identifiable actor is held, especially by the
held, especially by the community or the Internet public generally". community or the Internet public generally". We may call an
We may call an aggregation of individual assessments "reputation aggregation of individual assessments "reputation input."
information."
While the need for reputation information has been perhaps most clear While the need for reputation services has been perhaps especially
in the email world, where abuses are commonplace, other Internet clear in the email world, where abuses are commonplace, other
services are coming under attack and may have a similar need. For Internet services are coming under attack and may have a similar
instance, a reputation mechanism could be useful in rating the need. For instance, a reputation mechanism could be useful in rating
security of web sites; the quality of service of an Internet Service the security of web sites, the quality of service of an Internet
Provider (ISP) or Application Service Provider (ASP); customer Service Provider (ISP), or an Application Service Provider (ASP).
satisfaction at e-commerce sites; and even things unrelated to More generally, there are many different opportunities for use of
Internet protocols, such as plumbers, hotels, or books. Just as reputation services, such as customer satisfaction at e-commerce
human beings traditionally rely on the recommendations of trusted sites, and even things unrelated to Internet protocols, such as
parties in the physical world, so too they can be expected to make plumbers, hotels, or books. Just as human beings traditionally rely
use of such reputation information in a variety of applications on on the recommendations of trusted parties in the physical world, so
the Internet. too they can be expected to make use of such reputation services 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, exchanging,
consuming trust-related information. One component of that is a and consuming trust-related information. One component of that is a
query mechanism, to permit retrieval of reputation information. Not query mechanism, to permit retrieval of a reputation. Not all such
all such reputation services will need to convey the same reputation services will need to convey the same information. Some
information. Some need only produce a basic rating, while others need only produce a basic rating, while others need to provide
need to provide underlying detail. This is akin to the difference underlying detail. This is akin to the difference between check
between check approval versus a credit report. 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, a model defines a receive very different ratings on each. Therefore, the model defines
generic query mechanism and basic format for reputation information, a generic query mechanism and basic format for reputation retrieval,
but allows extensions for each application. but allows extensions for each application.
Omitted from this model is the means by which an reputation-reporting Omitted from this model is the means by which a reputation-reporting
agent goes about collecting such data and the mechanism for creating agent goes about collecting such data and the method for creating an
an evaluation. The mechanism defined here merely enables asking a evaluation. The mechanism defined here merely enables asking a
question and getting an answer; the remainder of an overall service question and getting an answer; the remainder of an overall service
provided by such a reputation agent is specific to the implementation provided by such a reputation agent is specific to the 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
that depicted in Figure 1 of [RFC5863], reproduced here: that depicted in Figure 1 of [RFC5863], reproduced here:
+------+------+ +------+------+ +------+------+ +------+------+
skipping to change at page 7, line 31 skipping to change at page 7, line 31
also includes the name of the application for which the reputation also includes the name of the application for which the reputation
data is being expressed. data is being expressed.
Each application requires its own specification of the Response Set. Each application requires its own specification of the Response Set.
For example, a specification might be needed for a reputation For example, a specification might be needed for a reputation
Response Set for an "email-sending-domain"; the Response Set might Response Set for an "email-sending-domain"; the Response Set might
include information on how often spam was received from that domain. include information on how often spam was received from that domain.
Additional documents define a [MIME] type for reputation data, and Additional documents define a [MIME] type for reputation data, and
protocols for exchanging such data. protocols for exchanging such data.
5. Information Flow in the Protocol 5. Information Flow in the Reputation Query 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 could be [MIME] or a DNS RR, and transported accordingly. It also could be
the integral payload of a purpose-built protocol. For a basic the integral payload of a purpose-built protocol. For a basic
request/response scenario, one entity (the Client) will ask a second request/response scenario, one entity (the Client) will ask a second
entity (the Server) for reputation data about a third entity (the entity (the Server) for reputation data about a third entity (the
Target), 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. This memo presents no actions for IANA.
[RFC Editor: Please remove this section prior to publication.]
7. Privacy Considerations 7. Privacy Considerations
Some kinds of reputation data are sensitive, and should not be shared Some kinds of reputation data are sensitive, and should not be shared
publicly. For applications that have such sensitivity, it is publicly. For cases that have such sensitivity, it is imperative to
imperative to pick a transport that will provide the required protect the information from unauthorized access and viewing. The
authentication and authorization mechanisms in order to secure model described here neither suggests nor precludes any particular
communication and deliver responses correctly according to the transport mechanism for the data. However, for the purpose of
proferred credentials. Such transport questions are the province of illustration, a reputation service that operates over HTTP might
the application definitions. employ any of its well-known mechanisms to solve these problems,
which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and
S/MIME [SMIME].
8. Security Considerations 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.
8.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 effect 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 a reputation
information about a DNS domain found in email messages could result about a DNS domain found in email messages could result in the
in the admission of spam, phishing or malware through a mail gateway admission of spam, phishing or malware through a mail gateway (by
(by rating the domain name more favourably than warranted) or could rating the domain name more favourably than warranted) or could
result in the needless rejection or delay of mail (by rating the result in the needless rejection or delay of mail (by rating the
domain more unfavourably than warranted). As a possible mitigation domain more unfavourably than warranted). As a possible mitigation
strategy, clients might seek to interact only with reputation strategy, clients might seek to interact only with reputation
services that offer some disclosure of the computation methods for services that offer some disclosure of the computation methods for
the results they return. Such disclosure and evaluation is beyond the results they return. Such disclosure and evaluation is beyond
the scope of the present memo. 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
skipping to change at page 9, line 40 skipping to change at page 9, line 40
Reputation Services", draft-ietf-repute-considerations Reputation Services", draft-ietf-repute-considerations
(work in progress), November 2012. (work in progress), November 2012.
[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.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[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.
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2: Message
Specification", RFC 5751, January 2010.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 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
https://www.ietf.org/mailman/listinfo/domainrep. https://www.ietf.org/mailman/listinfo/domainrep.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
68 lines changed or deleted 84 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/