draft-ietf-repute-model-09.txt   draft-ietf-repute-model-10.txt 
REPUTE Working Group N. Borenstein REPUTE Working Group N. Borenstein
Internet-Draft Mimecast Internet-Draft Mimecast
Intended status: Standards Track M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: March 16, 2014 Expires: March 21, 2014
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
September 12, 2013 September 17, 2013
An Architecture for Reputation Reporting An Architecture for Reputation Reporting
draft-ietf-repute-model-09 draft-ietf-repute-model-10
Abstract Abstract
This document describes a general architecture for a reputation-based This document describes a general architecture for a reputation-based
service, allowing one to request reputation-related data over the service, allowing one to request 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 March 16, 2014. This Internet-Draft will expire on March 21, 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Related Documents . . . . . . . . . . . . . . . . . . . . . . 5 3. Related Documents . . . . . . . . . . . . . . . . . . . . . . 5
4. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5 4. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5
4.1. Example of a Reputation Service Being Used . . . . . . . . 6 4.1. Example of a Reputation Service Being Used . . . . . . . . 6
5. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 5. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Assertions and Ratings . . . . . . . . . . . . . . . . . . 8 5.3. Assertions and Ratings . . . . . . . . . . . . . . . . . . 9
5.4. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Information Represented in a Response Set . . . . . . . . . . 9 6. Information Represented in the Protocol . . . . . . . . . . . 9
7. Information Flow in the Reputation Query Protocol . . . . . . 10 7. Information Flow in the Reputation Query Protocol . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
9.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 10 9.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 11
9.2. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11
9.3. Collection Of Data . . . . . . . . . . . . . . . . . . . . 11 9.3. Collection Of Data . . . . . . . . . . . . . . . . . . . . 12
9.4. Queries Can Reveal Information . . . . . . . . . . . . . . 11 9.4. Queries Can Reveal Information . . . . . . . . . . . . . . 12
9.5. Compromised Relationships . . . . . . . . . . . . . . . . 12 9.5. Compromised Relationships . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 12 10.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 13
10.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 13 10.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 13
10.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 13 10.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . . 13 11. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 14 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 the Simple Mail path. Similarly, a sending email server using the Simple Mail
Transfer Protocol [SMTP] trusts that the Domain Name System [DNS] has Transfer Protocol [SMTP] trusts that the Domain Name System [DNS] has
led it to the intended receiving server. Both kinds of trust are led it to the intended receiving server. Both kinds of trust are
skipping to change at page 5, line 45 skipping to change at page 5, line 45
This document outlines the reputation query and response mechanism. This document outlines the reputation query and response mechanism.
It provides the following definitions: It provides the 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 Query/response transport conventions. o Query/response transport conventions.
It provides an extremely simple query/response model that can be It provides an extremely simple query/response model that can be
carried over a variety of transports, including the Domain Name carried over a variety of transports, including the Domain Name
System. (Although not typically thought of as a 'transport', the DNS System. (Although not typically thought of as a 'transport', the DNS
provides generic capabilities and can be thought of as a mechanism provides generic capabilities and can be thought of as a mechanism
for transporting queries and responses that have nothing to do with for transporting queries and responses that have nothing to do with
Internet addresses, such as is done with a DNS BlockList [DNSBL].) Internet addresses, such as is done with a DNS BlockList [DNSBL].)
Each specification for Repute transport is independent of any other Each specification for Repute transport is independent of any other
specification. specification.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
5.1. Application 5.1. Application
An "Application" is a specific context in which reputation queries An "Application" is a specific context in which reputation queries
are made. Some obvious popular examples include restaurants, movies, are made. Some obvious popular examples include restaurants, movies,
or providers of various services. or providers of various services.
Applications have different sets of attributes of interest, and so Applications have different sets of attributes of interest, and so
the subjects of queries and the resulting responses will vary, in the subjects of queries and the resulting responses will vary in
order to describe the reputations of entities in their respective order to describe the reputations of entities in their respective
contexts. For example, the Application "movies" would have a contexts. For example, the Application "movies" would have a
different set of properties of interest and associated ratings (see different set of properties of interest and associated ratings (see
below) from "restaurants", so it's necessary for them to be formally below) from "restaurants". It is therefore necessary for them to be
enumerated. formally defined.
5.2. Response Set 5.2. Response Set
A "Response Set" is a representation for data that are returned in A "Response Set" is a representation for data that are returned in
response to a reputation query about a particular entity within the response to a reputation query about a particular entity within the
context of an Application. The content of the Response Set is context of an Application. A Response Set will always contain at
specific to the application; though all applications have a few key least the following components:
fields in common, some of the reputation data returned in the
evaluation of email senders would be different than that returned
about a movie, restaurant, or baseball player.
Response Sets have symbolic names, and these have to be registered o the name of the entity being rated;
with IANA, in the Reputation Applications Registry, to prevent name
collisions. (IANA registries are created in a separate document.) o the Assertion (see Section 5.3);
Each definition of a Response Set also needs to specify its registry
entry, which will include a document that details the content of a o the Rating (see Section 5.3).
Response Set within that Application.
The full content of the Response Set is specific to the Application;
though all Applications have these few key response set fields in
common, some of the reputation data returned in the evaluation of
email senders would be different than that returned about a movie,
restaurant, or baseball player. The specific meaning of a Rating is
also specific to an Application.
A Response Set is declared in a specification document, along with a
symbolic name representing the Application. The specifying documents
will include the details of query parameters and responses particular
to that Application. The symbolic names and corresponding specifying
documents are registered with IANA in the Reputation Applications
Registry in order to prevent name collisions and provide convenient
references to the documents.
IANA registries are created in a separate document.
5.3. Assertions and Ratings 5.3. Assertions and Ratings
One of the key properties of a Response Set is called an Assertion. One of the key properties of a Response Set is called an Assertion.
Assertions are claims made about the subject of a reputation query. Assertions are claims made about the subject of a reputation query.
For example, one might assert that a particular restaurant serves For example, one might assert that a particular restaurant serves
good food. In the context of this architecture, the assertion would good food. In the context of this architecture, the assertion would
be "serves good food". be "serves good food".
Assertions are coupled with a numeric value called a Rating, which is Assertions are coupled with a numeric value called a Rating, which is
skipping to change at page 9, line 29 skipping to change at page 9, line 41
strong as a value of "x/2". It also allows easier aggregation of strong as a value of "x/2". It also allows easier aggregation of
ratings collected from multiple reputation service providers. ratings collected from multiple reputation service providers.
5.4. Reputon 5.4. 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 in a serialized form. Its specific encoding is subject of the query in a serialized form. Its specific encoding is
left to documents that implement this architecture. left to documents that implement this architecture.
6. Information Represented in a Response Set 6. Information Represented in the Protocol
The basic information to be represented in the protocol is fairly Regardless of the transport selected for the interchange, the basic
simple, and includes at least the following data: information to be represented in the protocol is fairly simple, and
normally includes at least the following data:
In the query:
o the subject of the query;
o the name of the reputation context ("Application"; see
Section 5.1);
o optionally, name(s) of the specific reputation assertions of
interest.
Different transports, or different reputation contexts, might need
additional query parameters.
In the response:
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 application context for the query (e.g., email address o the application context for the query (e.g., email address
evaluation); evaluation);
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 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 is included for specific uses of the service. The entire collection of
the Response Set for that application. The query/response protocol data found in the response is the Response Set for that application,
defines a syntax for representing such Response Sets, but each and is defined in specifying documents as described above.
application defines its own Response Set. Thus, the basic information
also includes the name of the application for which the reputation
data is being expressed.
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
protocols for exchanging such data. Additional documents define a media type and format for reputation
data, and protocols for exchanging such data.
7. Information Flow in the Reputation Query Protocol 7. 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
subject), and the second entity will respond with those data. subject), and the second entity will respond with those data.
skipping to change at page 11, line 12 skipping to change at page 11, line 35
when a client is talking to a server outside of its own when a client is talking to a server outside of its own
administrative domain. Furthermore, certain types of reputation administrative domain. Furthermore, certain types of reputation
information are typically perceived as more sensitive than others; information are typically perceived as more sensitive than others;
movie ratings, for example, are much less damaging if leaked than a movie ratings, for example, are much less damaging if leaked than a
person's credit rating. person's credit rating.
For interchanges that are sensitive to such exposures, it is For interchanges that are sensitive to such exposures, it is
imperative to protect the information from unauthorized access and imperative to protect the information from unauthorized access and
viewing, and possibly add the capability to do object-level integrity viewing, and possibly add the capability to do object-level integrity
and origin verification. Not all transport options can be adequately and origin verification. Not all transport options can be adequately
secured in these ways (e.g., DNS queries and responses are entirely secured in these ways. In particular, DNS queries and responses are
insecure), and so it might be necessary to change to a transport entirely insecure. Services MUST use a transport method that
method that does have such capabilities or extensions. provides adequate security when privacy-sensitive data are involved.
The architecture described here neither suggests nor precludes any The architecture described here neither suggests nor precludes any
particular transport mechanism for the data. However, for the particular transport mechanism for the data. An HTTP mechanism is
purpose of illustration, a reputation service that operates over HTTP defined in [I-D.REPUTE-QUERY-HTTP], and email-based mechanisms are
might employ any of several well-known mechanisms to solve these also envisioned. For HTTP, use of HTTP over TLS [HTTP-TLS] is very
problems, which include OpenPGP [OPENPGP], HTTP over TLS [HTTP-TLS], strongly advised. For email, mechanisms such as OpenPGP [OPENPGP]
and S/MIME [SMIME]. and S/MIME [SMIME] are similarly advised.
9.2. Aggregation 9.2. Aggregation
The data that are collected as input to a reputation calculation are 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 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 another. What one party says about another is often meant to be kept
in confidence. Accordingly, steps often need to be taken to secure in confidence. Accordingly, steps often need to be taken to secure
the submission of these input data to a reputation service provider. the submission of these input data to a reputation service provider.
Moreover, although the aggregated reputation is the product provided Moreover, although the aggregated reputation is the product provided
 End of changes. 23 change blocks. 
56 lines changed or deleted 75 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/