draft-ietf-repute-model-02.txt   draft-ietf-repute-model-03.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: December 17, 2012 Cloudmark Expires: May 17, 2013 Cloudmark
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
June 15, 2012 November 13, 2012
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-02 draft-ietf-repute-model-03
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 December 17, 2012. This Internet-Draft will expire on May 17, 2013.
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
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 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
9. Informative References . . . . . . . . . . . . . . . . . . . . 9 8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
an evaluation. The mechanism defined here merely enables asking a an 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:
+------+------+ +------+------+ +------+------+ +------+------+
| Author | | Recipient | | Author | | Recipient |
+------+------+ +------+------+ +------+------+ +------+------+
| ^ | ^
| | | |
| +------+------+ | +------+------+
| -->| Handling |<-- | -->| Handling |<--
| -->| Filter |<-- | -->| Filter |<--
| +-------------+ | +-------------+
| ^ | ^
V Responsible | V Responsible |
+-------------+ Identifier +------+------+ +-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity | | Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor | | Identity | . . | Assessor |
+------+------+ . . +-------------+ +------+------+ . . +-------------+
| V . ^ ^ | V . ^ ^
V . . | | V . . | |
+------------------.-------.--------------------+ | | +------------------.-------.------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+ | +------+------+ . . . > . +-------------+ | | | +------------+
| | Identifier | | Identifier +--|--+ +--+ Assessment| | | Identifier | | Identifier +-|-+ +-+ Assessment |
| | 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.
This memo outlines the query and response mechanism. It provides the This memo outlines the query and response mechanism. It provides the
following definitions: following definitions:
o Vocabulary for the current work and work of this type; o Vocabulary for the current work and work of this type;
skipping to change at page 9, line 9 skipping to change at page 9, line 9
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 the reputation service. This might result of the agency providing the reputation service. This might result
from an attack on the data being returned at the source, or from a from an attack on the data being returned at the source, or from a
man-in-the-middle attack. Protocols, therefore, need to be designed man-in-the-middle attack. Protocols, therefore, need to be designed
so as to be as resilient against such attacks as possible. so as to be as resilient against such attacks as possible.
8.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. Malformations can be used to confound clients and servers alike in
terms of identifying the party or parties responsible for the content
under evaluation. This can result in delivery of undesirable or even
dangerous content.
8.3. Further Discussion
Numerous other topics related to use and management of reputation
systems can be found in [I-D.REPUTE-CONSIDERATIONS].
9. 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.
[I-D.REPUTE-CONSIDERATIONS]
Kucherawy, M., "Operational Considerations Regarding
Reputation Services", draft-ietf-repute-considerations
(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.
[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.
 End of changes. 8 change blocks. 
43 lines changed or deleted 57 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/