draft-ietf-repute-model-07.txt   draft-ietf-repute-model-08.txt 
REPUTE Working Group N. Borenstein REPUTE Working Group N. Borenstein
Internet-Draft Mimecast Internet-Draft Mimecast
Intended status: Informational M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: January 13, 2014 Expires: February 28, 2014
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
July 12, 2013 August 27, 2013
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-07 draft-ietf-repute-model-08
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 requesting reputation-related data over the service and a model for requesting reputation-related data over the
Internet, where "reputation" refers to predictions or expectations Internet, where "reputation" refers to predictions or expectations
about an entity or an identifier such as a domain name. The document about an entity or an identifier such as a domain name. The document
roughly follows the recommendations of RFC4101 for describing a roughly follows the recommendations of RFC4101 for describing a
protocol model. protocol model.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 13, 2014. This Internet-Draft will expire on February 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5 3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5
4. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 7
4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Information Represented in a Response Set . . . . . . . . . . 8 5. Information Represented in a Response Set . . . . . . . . . . 8
6. Information Flow in the Reputation Query Protocol . . . . . . 8 6. Information Flow in the Reputation Query Protocol . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9
8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 9 8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 9
8.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 9 8.2. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.3. Collection Of Data . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 10 9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 10
9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 10 9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 11
9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 10 9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . . . 10 10. Informative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 11 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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 8, line 5 skipping to change at page 8, line 5
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, in the Reputation Applications Registry, to prevent name with IANA, in the Reputation Applications Registry, to prevent name
collisions. IANA registries are created in a separate document. collisions. IANA registries are created in a separate document.
Each definition of a Response Set also needs to define its registry Each definition of a Response Set also needs to define its registry
entry. entry.
4.1.1. Assertions and Ratings
One of the key properties of a Response Set is called an Assertion.
Assertions are claims made about the subject of a reputation query.
For example, one might assert that a particular restaurant serves
good food. In the context of this model, the assertion would be
"serves good food".
Assertions are coupled with a numeric value called a Rating, which is
an indication of how much the party generating the Response Set
agrees with the assertion being made. For example, with the above
Assertion, a rating of 1.0 indicates strong agreement, while a rating
of 0.0 indicates no support for the assertion.
4.2. Reputon 4.2. Reputon
A "reputon" is an object that comprises the basic response to a A "reputon" is an object that comprises the basic response to a
reputation query. It contains the response set relevant to the reputation query. It contains the response set relevant to the
subject of the query. Its specific encoding is left to documents subject of the query. Its specific encoding is left to documents
that implement this model. that implement this model.
5. Information Represented in a Response Set 5. 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
skipping to change at page 9, line 31 skipping to change at page 9, line 45
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 cases that have such sensitivity, it is imperative to publicly. For cases that have such sensitivity, it is imperative to
protect the information from unauthorized access and viewing. The protect the information from unauthorized access and viewing. The
model described here neither suggests nor precludes any particular model described here neither suggests nor precludes any particular
transport mechanism for the data. However, for the purpose of transport mechanism for the data. However, for the purpose of
illustration, a reputation service that operates over HTTP might illustration, a reputation service that operates over HTTP might
employ any of its well-known mechanisms to solve these problems, employ any of its well-known mechanisms to solve these problems,
which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and
S/MIME [SMIME]. S/MIME [SMIME].
8.2. Collection Of Data 8.2. Aggregation
The data that are collected as input to a reputation calculation are
in essence a statement by one party about the actions or output of
another. What one party says about another is often meant to be kept
in confidence. Accordingly, steps often need to be taken to secure
the submission of these input data to a reputation service provider.
Moreover, although the aggregated reputation is the product provided
by this service, its inadvertent exposure can have undesirable
effects. Just as the collection of data about a subject needs due
consideration to privacy and security, so too does the output and
storage of whatever aggregation the service provider applies.
8.3. Collection Of Data
The basic notion of collection and storage of reputation data is The basic notion of collection and storage of reputation data is
obviously a privacy issue in that the opinions of one party about obviously a privacy issue in that the opinions of one party about
another are likely to be sensitive. Inadvertent or unauthorized another are likely to be sensitive. Inadvertent or unauthorized
exposure of those data can lead to personal or commercial damage. exposure of those data can lead to personal or commercial damage.
9. Security Considerations 9. Security Considerations
This document introduces an overall protocol model, but no This document introduces an overall protocol model, but no
implementation details. As such, the security considerations implementation details. As such, the security considerations
 End of changes. 9 change blocks. 
14 lines changed or deleted 43 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/