draft-ietf-repute-model-10.txt   rfc7070.txt 
REPUTE Working Group N. Borenstein Internet Engineering Task Force (IETF) N. Borenstein
Internet-Draft Mimecast Request for Comments: 7070 Mimecast
Intended status: Standards Track M. Kucherawy Category: Standards Track M. Kucherawy
Expires: March 21, 2014 ISSN: 2070-1721 November 2013
A. Sullivan, Ed.
Dyn, Inc.
September 17, 2013
An Architecture for Reputation Reporting An Architecture for Reputation Reporting
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 RFC 4101 for describing a
protocol model. protocol model.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 21, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7070.
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
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. 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 .....................................7
5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Application ................................................7
5.2. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Response Set ...............................................7
5.3. Assertions and Ratings . . . . . . . . . . . . . . . . . . 9 5.3. Assertions and Ratings .....................................8
5.4. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Reputon ....................................................9
6. Information Represented in the Protocol . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 11 8. Privacy Considerations .........................................10
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 8.1. Data in Transit ...........................................10
9.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 11 8.2. Aggregation ...............................................11
9.2. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. Collection of Data ........................................11
9.3. Collection Of Data . . . . . . . . . . . . . . . . . . . . 12 8.4. Queries Can Reveal Information ............................11
9.4. Queries Can Reveal Information . . . . . . . . . . . . . . 12 8.5. Compromised Relationships .................................11
9.5. Compromised Relationships . . . . . . . . . . . . . . . . 12 9. Security Considerations ........................................12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9.1. Biased Reputation Agents ..................................12
10.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 13 9.2. Malformed Messages ........................................12
10.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 13 9.3. Further Discussion ........................................13
10.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 13 10. Informative References ........................................13
11. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 15
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 server that sends email 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
easily betrayed, opening the operation to subversion of some kind, easily betrayed, opening the operation to subversion of some kind,
which makes spam, phishing, and other attacks even easier than they which makes spam, phishing, and other attacks even easier than they
would othewise be. would otherwise be.
In recent years, explicit identity authentication mechanisms have In recent years, explicit identity authentication mechanisms have
begun to see wider deployment. For example, the [DKIM] protocol begun to see wider deployment. For example, the DomainKeys
permits associating a validated identifier to a message. This Identified Mail [DKIM] protocol permits associating a validated
association is cryptographically strong, and is an improvement over identifier to a message. This association is cryptographically
the prior state of affairs, but it does not distinguish between strong, and is an improvement over the prior state of affairs, but it
identifiers of good actors and bad. Even when it is possible to does not distinguish between identifiers of good actors and bad.
validate the domain name in an author field (e.g. Even when it is possible to validate the domain name in an author
"trustworthy.example.com" in "john.doe@trustworthy.example.com") field (e.g., "trustworthy.example.com" in
there is no basis for knowing whether it is associated with a good "john.doe@trustworthy.example.com"), there is no basis for knowing
actor worthy of trust. As a practical matter, both bad actors and whether it is associated with a good actor who is worthy of trust.
good adopt basic authentication mechanisms like DKIM. In fact, bad As a practical matter, both bad actors and good adopt basic
actors tend to adopt them even more rapidly than the good actors do authentication mechanisms like DKIM. In fact, bad actors tend to
in the hope that some receivers will confuse identity authentication adopt them even more rapidly than the good actors do in the hope that
with identity assessment. The former merely means that the name is some receivers will confuse identity authentication with identity
being used by its owner or their agent, while the latter makes a assessment. The former merely means that the name is being used by
statement about the quality of the owner. its owner or their agent, while the latter makes a statement about
the quality of the owner.
With the advent of these authentication protocols, it is possible to With the advent of these authentication protocols, it is possible to
statisfy the requirement for a mechanism by which mutually trusted satisfy the requirement for a mechanism by which mutually trusted
parties can exchange assessment information about other actors. For parties can exchange assessment information about other actors. For
these purposes, we may usefully define "reputation" as "the these purposes, we may usefully define "reputation" as "the
estimation in which an identifiable actor is held, especially by the estimation in which an identifiable actor is held, especially by the
community or the Internet public generally". (This is based on the community or the Internet public generally". (This is based on the
definition of "reputation" from the 2013 Random House dictionary.) definition of "reputation" in [RANDOMHOUSE].) We may call an
We may call an aggregation of individual assessments "reputation aggregation of individual assessments "reputation input".
input."
While the need for reputation services has been perhaps especially While the need for reputation services has been perhaps especially
clear in the email world, where abuses are commonplace, other clear in the email world, where abuses are commonplace, other
Internet services are coming under attack and may have a similar Internet services are coming under attack and may have a similar
need. For instance, a reputation mechanism could be useful in rating need. For instance, a reputation mechanism could be useful in rating
the security of web sites, the quality of service of an Internet the security of web sites, the quality of service of an Internet
Service Provider (ISP), or an Application Service Provider (ASP). Service Provider (ISP), or an Application Service Provider (ASP).
More generally, there are many different opportunities for use of More generally, there are many different opportunities for use of
reputation services, such as customer satisfaction at e-commerce reputation services, such as customer satisfaction at e-commerce
sites, and even things unrelated to Internet protocols, such as sites, and even things unrelated to Internet protocols, such as
skipping to change at page 4, line 17 skipping to change at page 4, line 17
too they can be expected to make use of such reputation services in a too they can be expected to make use of such reputation services in a
variety of applications on the Internet. 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, exchanging, activities, to enable an end-to-end service for creating, exchanging,
and 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 a reputation. Not all such query mechanism, to permit retrieval of a reputation. Not all such
reputation services will need to convey the same information. Some reputation services will need to convey the same information. Some
need only to produce a basic rating, while others need to provide need only to produce a basic rating, while others need to provide
underlying detail. This is akin to the difference between check underlying detail. This is akin to the difference between check
approval versus a credit report. approval and 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, the architecture receive very different ratings on each. Therefore, the architecture
defines a generic query mechanism and basic format for reputation defines a generic query mechanism and basic format for reputation
retrieval, but allows extensions for each application. retrieval, but allows extensions for each application.
Omitted from this architecture is the means by which a reputation- Omitted from this architecture is the means by which a reputation-
skipping to change at page 4, line 40 skipping to change at page 4, line 40
asking a question and getting an answer; the remainder of an overall asking a question and getting an answer; the remainder of an overall
service provided by such a reputation agent is specific to the service provided by such a reputation agent is specific to the
implementation of that service and is out of scope here. implementation of that service and is out of scope here.
2. Overview 2. Overview
The basic premise of this reputation system involves a client that is The basic premise of this reputation system involves a client that is
seeking to evaluate content based on an identifier associated with seeking to evaluate content based on an identifier associated with
the content, and a reputation service provider that collects, the content, and a reputation service provider that collects,
aggregates, and makes available for consumption, scores based on the aggregates, and makes available for consumption, scores based on the
collected data. Typically client and service operators enter into collected data. Typically, client and service operators enter into
some kind of agreement during which some parameters are exchanged, some kind of agreement during which some parameters are exchanged,
such as: the location at which the reputation service can be reached, such as: the location at which the reputation service can be reached,
the nature of the reputation data being offered, possibly some client the nature of the reputation data being offered, possibly some client
authentication details, and the like. authentication details, and the like.
Upon receipt of some content the client operator wishes to evaluate Upon receipt of some content the client operator wishes to evaluate
(an Internet message, for example), the client extracts from the (an Internet message, for example), the client extracts from the
content one or more identifiers of interest to be evaluated. content one or more identifiers of interest to be evaluated.
Examples of this include the domain name found in the From: field of Examples of this include the domain name found in the From: field of
a message, or the domain name extracted from a valid DomainKeys a message, or the domain name extracted from a valid DKIM signature.
Identified Mail (DKIM) signature.
Next, the goal is to ask the reputation service provider what the Next, the goal is to ask the reputation service provider what the
reputation of the extracted identifier is. The query will contain reputation of the extracted identifier is. The query will contain
the identifier to be evaluated and possibly some context-specific the identifier to be evaluated and possibly some context-specific
information (such as to establish the context of the query, e.g., an information (such as to establish the context of the query, e.g., an
email message) or client-specific information. The client typically email message) or client-specific information. The client typically
folds the data in the response into whatever local evaluation logic folds the data in the response into whatever local evaluation logic
it applies to decide what disposition the content deserves. it applies to decide what disposition the content deserves.
3. Related Documents 3. Related Documents
This document presents a high-level view of the reputation This document presents a high-level view of the reputation
architecture. architecture.
For the purposes of sending and receiving reputation information, For the purposes of sending and receiving reputation information,
[I-D.REPUTE-MEDIA-TYPE] defines a media type for containing responses [RFC7071] defines a media type for containing responses to reputation
to reputation queries, and a serialization format for these data queries, and a serialization format for these data (with examples).
(with examples). It also creates the registry for specific It also creates the registry for specific reputation contexts and the
reputation contexts and the parameters related to them. parameters related to them.
[I-D.REPUTE-QUERY-HTTP] describes how to construct and issue [RFC7072] describes how to construct and issue reputation queries and
reputation queries and replies in the context of this architecture replies in the context of this architecture using the HyperText
using the HyperText Transport Protocol (HTTP) as the query protocol. Transport Protocol (HTTP) as the query protocol.
Finally, [I-D.REPUTE-EMAIL-IDENTIFIERS] defines (and registers) a Finally, [RFC7073] defines (and registers) a first, common,
first, common, reputation application, namely the evaluation of reputation application, namely the evaluation of portions of an email
portions of an email message as subjects for reputation queries and message as subjects for reputation queries and replies.
replies.
4. High-Level Architecture 4. High-Level Architecture
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;
skipping to change at page 6, line 10 skipping to change at page 6, line 5
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.
The precise syntaxes of both the query and response are application- The precise syntaxes of both the query and response are application
specific. An application within this architecture defines the specific. An application within this architecture defines the
parameters available to queries of that type, and also defines the parameters available to queries of that type, and it also defines the
data returned in response to any query. data returned in response to any query.
4.1. Example of a Reputation Service Being Used 4.1. Example of a Reputation Service Being Used
A reputation mechanism functions as a component of an overall A reputation mechanism functions as a component of an overall
service. A current example is that of an email system that uses service. A current example is that of an email system that uses DKIM
DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable [DKIM] to affix a stable identifier to a message and then uses that
identifier to a message and then uses that as a basis for evaluation: as a basis for evaluation:
+-------------+ +------------+ +-------------+ +------------+
| Sender | | Recipient | | Sender | | Recipient |
+-------------+ +------------+ +-------------+ +------------+
| ^ | ^
V | V |
+-------------+ +------------+ +-------------+ +------------+
| MSA | | MDA | | MSA | | MDA |
+-------------+ +------------+ +-------------+ +------------+
| ^ | ^
skipping to change at page 7, line 39 skipping to change at page 7, line 5
| Signer | (DKIM) | Verifier | | Signer | (DKIM) | Verifier |
+------------+ +------------+ +------------+ +------------+
| ^ | ^
V | V |
+-------------+ /~~~~~~~~~~\ +------+-----+ +-------------+ /~~~~~~~~~~\ +------+-----+
| MTA |----->( other MTAs )------>| MTA | | MTA |----->( other MTAs )------>| MTA |
+-------------+ \~~~~~~~~~~/ +------------+ +-------------+ \~~~~~~~~~~/ +------------+
Figure 1: Actors in a Trust Sequence Using DKIM Figure 1: Actors in a Trust Sequence Using DKIM
(See [EMAIL-ARCH] for a general description of the Internet messaging See [EMAIL-ARCH] for a general description of the Internet messaging
architecture.) In this figure, the solid lines indicate the flow of architecture. In particular, the terms Message Submission Agent
a message; the dotted line indicates transfer of validated (MSA), Message Delivery Agent (MDA), and Message Transfer Agent (MTA)
identifiers within the message content; and the double line shows the are described there.
query and response of the reputation information.
In this figure, the solid lines indicate the flow of a message; the
dotted line indicates transfer of validated identifiers within the
message content; and the double line shows the query and response of
the reputation information.
Here, the DKIM Service provides one or more stable identifiers that Here, the DKIM Service provides one or more stable identifiers that
is the basis for the reputation query. On receipt of a message from is the basis for the reputation query. On receipt of a message from
an MTA, the DKIM Service provides a (possibly empty) set of validated an MTA, the DKIM Service provides a (possibly empty) set of validated
identifiers -- domain names, in this case -- which are the subjects identifiers -- domain names, in this case -- that are the subjects of
of reputation queries made by the Identity Assessor. The Identifier reputation queries made by the Identifier Assessor. The Identifier
Assessor queries a Reputation Service to determine the reputation of Assessor queries a Reputation Service to determine the reputation of
the provided identifiers, and delivers the identifiers and their the provided identifiers, and delivers the identifiers and their
reputations to the Handling Filter. The Handling Filter makes a reputations to the Handling Filter. The Handling Filter makes a
decision about whether and how to deliver the message to the decision about whether and how to deliver the message to the
recipient based on these and other inputs about the message, possibly recipient based on these and other inputs about the message, possibly
including evaluation mechanisms in addition to DKIM. including evaluation mechanisms in addition to DKIM.
5. Terminology and Definitions 5. 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.
skipping to change at page 8, line 34 skipping to change at page 8, line 4
formally defined. 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. A Response Set will always contain at context of an Application. A Response Set will always contain at
least the following components: least the following components:
o the name of the entity being rated; o the name of the entity being rated;
o the Assertion (see Section 5.3); o the Assertion (see Section 5.3);
o the Rating (see Section 5.3). o the Rating (see Section 5.3).
The full content of the Response Set is specific to the Application; The full content of the Response Set is specific to the Application;
though all Applications have these few key response set fields in though all Applications have these few key Response Set fields in
common, some of the reputation data returned in the evaluation of common, some of the reputation data returned in the evaluation of
email senders would be different than that returned about a movie, email senders would be different than that returned about a movie,
restaurant, or baseball player. The specific meaning of a Rating is restaurant, or baseball player. The specific meaning of a Rating is
also specific to an Application. also specific to an Application.
A Response Set is declared in a specification document, along with a A Response Set is declared in a specification document, along with a
symbolic name representing the Application. The specifying documents symbolic name representing the Application. The specifying documents
will include the details of query parameters and responses particular will include the details of query parameters and responses particular
to that Application. The symbolic names and corresponding specifying to that Application. The symbolic names and corresponding specifying
documents are registered with IANA in the Reputation Applications documents are registered with IANA in the "Reputation Applications"
Registry in order to prevent name collisions and provide convenient registry in order to prevent name collisions and provide convenient
references to the documents. references to the documents.
IANA registries are created in a separate document. IANA registries are created in [RFC7071].
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
an indication of how much the party generating the Response Set is an indication of how much the party generating the Response Set
agrees with the assertion being made. Ratings are typically agrees with the assertion being made. Ratings are typically
expressed as a floating point value between 0.0 and 1.0 inclusive, expressed as a floating point value between 0.0 and 1.0 inclusive,
with the former indicating no support for the assertion and the with the former indicating no support for the assertion and the
latter indicating total agreement with the assertion. latter indicating total agreement with the assertion.
The documents that define applications will also specify the type of The documents that define future applications will also specify the
scale in use when generating ratings, to which all reputation service type of scale in use when generating ratings, to which all reputation
providers for that application space must adhere. This will allow a service providers for that application space must adhere. This will
client to change which reputation service provider is being queried allow a client to change which reputation service provider is being
without having to learn through some out-of-band method what the new queried without having to learn through some out-of-band method what
provider's ratings mean. For example, a registration might state the new provider's ratings mean. For example, a registration might
that ratings are linear, which would mean a score of "x" is twice as state that ratings are linear, which would mean a score of "x" is
strong as a value of "x/2". It also allows easier aggregation of twice as strong as a value of "x/2". It also allows easier
ratings collected from multiple reputation service providers. aggregation of 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 the Protocol 6. Information Represented in the Protocol
Regardless of the transport selected for the interchange, the basic Regardless of the transport selected for the interchange, the basic
information to be represented in the protocol is fairly simple, and information to be represented in the protocol is fairly simple, and
normally includes at least the following data: normally includes at least the following data:
In the query: In the query:
skipping to change at page 10, line 26 skipping to change at page 9, line 44
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.
Beyond this, arbitrary amounts of additional information might be Beyond this, arbitrary amounts of additional information might be
included for specific uses of the service. The entire collection of included for specific uses of the service. The entire collection of
data found in the response is the Response Set for that application, data found in the response is the Response Set for that application
and is defined in specifying documents as described above. and is defined in specifying documents as described above.
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 media type and format for reputation [RFC7071] defines a media type and format for reputation data, and
data, and protocols for exchanging such data. [RFC7072] describes a protocol 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 Resource Record (RR), and transported accordingly.
the integral payload of a purpose-built protocol. For a basic It also could be the integral payload of a purpose-built protocol.
request/response scenario, one entity (the client) will ask a second For a basic request/response scenario, one entity (the client) will
entity (the server) for reputation data about a third entity (the ask a second entity (the server) for reputation data about a third
subject), and the second entity will respond with those data. entity (the subject), and the second entity will respond with those
data.
An application might benefit from an extremely lightweight mechanism, An application might benefit from an extremely lightweight mechanism,
supporting constrained queries and responses, while others might need supporting constrained queries and responses, while others might need
to support larger and more complex responses. to support larger and more complex responses.
8. IANA Considerations 8. Privacy Considerations
This document presents no actions for IANA.
[RFC Editor: Please remove this section prior to publication.]
9. Privacy Considerations
9.1. Data In Transit 8.1. Data in Transit
Some reputation exchanges can be sensitive, and should not be shared Some reputation exchanges can be sensitive, and should not be shared
publicly. A client making use of this framework is explicitly publicly. A client making use of this framework is explicitly
revealing that it is interested in particular subjects, and the revealing that it is interested in particular subjects, and the
server is revealing what its information sources have reported about server is revealing what its information sources have reported about
those subjects (in the aggregate). In the email context, for those subjects (in the aggregate). In the email context, for
example, a client is revealing from whom it receives email, and the example, a client is revealing from whom it receives email, and the
server is revealing what it (based on its aggregated data) believes server is revealing what it (based on its aggregated data) believes
to be true about those subjects. to be true about those subjects.
skipping to change at page 11, line 36 skipping to change at page 10, line 44
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. In particular, DNS queries and responses are secured in these ways. In particular, DNS queries and responses are
entirely insecure. Services MUST use a transport method that entirely insecure. Services need to use a transport method that
provides adequate security when privacy-sensitive data are involved. 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. An HTTP mechanism is particular transport mechanism for the data. An HTTP mechanism is
defined in [I-D.REPUTE-QUERY-HTTP], and email-based mechanisms are defined in [RFC7072], and email-based mechanisms are also envisioned.
also envisioned. For HTTP, use of HTTP over TLS [HTTP-TLS] is very For HTTP, use of HTTP over Transport Layer Security [HTTP-TLS] is
strongly advised. For email, mechanisms such as OpenPGP [OPENPGP] very strongly advised. For email, mechanisms such as OpenPGP
and S/MIME [SMIME] are similarly advised. [OPENPGP] and S/MIME [SMIME] are similarly advised.
9.2. Aggregation 8.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
by this service, its inadvertent exposure can have undesirable by this service, its inadvertent exposure can have undesirable
effects. Just as the collection of data about a subject needs due effects. Just as the collection of data about a subject needs due
consideration to privacy and security, so too does the output and consideration to privacy and security, so too does the output and
storage of whatever aggregation the service provider applies. storage of whatever aggregation the service provider applies.
9.3. Collection Of Data 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.4. Queries Can Reveal Information 8.4. Queries Can Reveal Information
When a client asks a service provider about a particular subject, the When a client asks a service provider about a particular subject, the
service provider can infer the existence of that subject and begin service provider can infer the existence of that subject and begin
observing which clients ask about it. This can be an unanticipated observing which clients ask about it. This can be an unanticipated
leak of private information. leak of private information.
9.5. Compromised Relationships 8.5. Compromised Relationships
Reputation services that limit queries to authorized clients can Reputation services that limit queries to authorized clients can
cause private information, such as the reputations themselves or the cause private information, such as the reputations themselves or the
data used to compute them, to be revealed if the client credentials data used to compute them, to be revealed if the client credentials
are compromised. It is critical to safeguard not only the are compromised. It is critical to safeguard not only the
interchange of reputation information, and the information once it interchange of reputation information, and the information once it
has been delivered to the client, but the ability to issue requests has been delivered to the client, but the ability to issue requests
for information as well. for information as well.
An important consideration here is that compromised credentials are An important consideration here is that compromised credentials are
mainly an exposure of some third party (whose reputation is mainly an exposure of some third party (whose reputation is
improperly revealed), rather than the client or the server. improperly revealed) rather than the client or the server.
10. Security Considerations 9. Security Considerations
This document introduces an overall protocol architecture, but no This document introduces an overall protocol architecture, but no
implementation details. As such, the security considerations implementation details. As such, the security considerations
presented here are very high-level. The detailed analyses of the presented here are very high level. The detailed analysis of the
various specific components of the protocol can be found the various specific components of the protocol can be found in the
documents that instantiate this architecture. documents that instantiate this architecture.
10.1. Biased Reputation Agents 9.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 a reputation might have. For example, a biased system returning a reputation
about a DNS domain found in email messages could result in the about a DNS domain found in email messages could result in the
admission of spam, phishing or malware through a mail gateway (by admission of spam, phishing, or malware through a mail gateway (by
rating the domain name more favourably than warranted) or could rating the domain name more favorably than warranted) or could result
result in the needless rejection or delay of mail (by rating the in the needless rejection or delay of mail (by rating the domain more
domain more unfavourably than warranted). As a possible mitigation unfavorably than warranted). As a possible mitigation strategy,
strategy, clients might seek to interact only with reputation clients might seek to interact only with reputation services that
services that offer some disclosure of the computation methods for offer some disclosure of the computation methods for the results they
the results they return. Such disclosure and evaluation is beyond return. Such disclosure and evaluation is beyond the scope of the
the scope of the present document. present document.
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 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.
10.2. Malformed Messages 9.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.
Malformations can be used to confound clients and servers alike in Malformations can be used to confound clients and servers alike in
terms of identifying the party or parties responsible for the content terms of identifying the party or parties responsible for the content
under evaluation. This can result in delivery of undesirable or even under evaluation. This can result in delivery of undesirable or even
dangerous content. dangerous content.
10.3. Further Discussion 9.3. Further Discussion
Involving a third party (in this case, a reputation service provider) Involving a third party (in this case, a reputation service provider)
that can influence the handling of incoming content involves ceding that can influence the handling of incoming content involves ceding
some amount of control to that third party. Numerous other topics some amount of control to that third party. Numerous other topics
related to the management, operation, and safe use of reputation related to the management, operation, and safe use of reputation
systems can be found in [I-D.REPUTE-CONSIDERATIONS]. systems can be found in [CONSIDERATIONS].
11. Informative References
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 10. Informative References
"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
[DNS] Mockapetris, P., "Domain names - implementation and [CONSIDERATIONS]
specification", STD 13, RFC 1035, November 1987. Kucherawy, M., "Operational Considerations Regarding
Reputation Services", Work in Progress, May 2013.
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
February 2010. Ed., "DomainKeys Identified Mail (DKIM) Signatures",
STD 76, RFC 6376, September 2011.
[EMAIL-ARCH] [DNS] Mockapetris, P., "Domain names - implementation and
Crocker, D., "Internet Mail Architecture", RFC 5598, specification", STD 13, RFC 1035, November 1987.
July 2009.
[HTTP-TLS] [DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. February 2010.
[I-D.REPUTE-CONSIDERATIONS] [EMAIL-ARCH]
Kucherawy, M., "Operational Considerations Regarding Crocker, D., "Internet Mail Architecture", RFC 5598,
Reputation Services", draft-ietf-repute-considerations July 2009.
(work in progress), November 2012.
[I-D.REPUTE-EMAIL-IDENTIFIERS] [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary
for Email Identifiers",
draft-ietf-repute-email-identifiers (work in progress),
November 2012.
[I-D.REPUTE-MEDIA-TYPE] [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
Borenstein, N. and M. Kucherawy, "A Media Type for October 2008.
Reputation Interchange", draft-ietf-repute-media-type
(work in progress), November 2012.
[I-D.REPUTE-QUERY-HTTP] [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Borenstein, N. and M. Kucherawy, "Reputation Data Extensions (MIME) Part One: Format of Internet Message
Interchange using HTTP and XML", Bodies", RFC 2045, November 1996.
draft-ietf-repute-query-http (work in progress),
November 2012.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
October 2008. Thayer, "OpenPGP Message Format", RFC 4880,
November 2007.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RANDOMHOUSE]
Extensions (MIME) Part One: Format of Internet Message "Random House Webster's Dictionary, Revised Edition",
Bodies", RFC 2045, November 1996. ISBN 978-0-345-44725-8, June 2001.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Reputation Interchange", RFC 7071, November 2013.
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC7072] Borenstein, N. and M. Kucherawy, "A Reputation Query
Mail Extensions (S/MIME) Version 3.2: Message Protocol", RFC 7072, November 2013.
Specification", RFC 5751, January 2010.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC7073] Borenstein, N. and M. Kucherawy, "A Reputation Response
October 2008. Set for Email Identifiers", RFC 7073, November 2013.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Reference", RFC 5518, April 2009. Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
Appendix A. Public Discussion [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
Public discussion of this suite of documents takes place on the [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
domainrep@ietf.org mailing list. See Reference", RFC 5518, April 2009.
https://www.ietf.org/mailman/listinfo/domainrep.
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
270 Upland Drive 270 Upland Drive
San Francisco, CA 94127 San Francisco, CA 94127
USA
Email: superuser@gmail.com
Andrew Sullivan (editor)
Dyn, Inc.
150 Dow St.
Manchester, NH 03101
USA USA
Email: asullivan@dyn.com EMail: superuser@gmail.com
 End of changes. 74 change blocks. 
218 lines changed or deleted 187 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/