An Architecture for Reputation Reporting
RFC 7070
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7070 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
An Architecture for Reputation Reporting
Abstract
This document describes a general architecture for a reputation-based
service, allowing one to request reputation-related data over the
Internet, where "reputation" refers to predictions or expectations
about an entity or an identifier such as a domain name. The document
roughly follows the recommendations of RFC 4101 for describing a
protocol model.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
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 (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Borenstein & Kucherawy Standards Track [Page 1]
RFC 7070 Reputation Architecture November 2013
Table of Contents
1. Introduction ....................................................3
2. Overview ........................................................4
3. Related Documents ...............................................5
4. High-Level Architecture .........................................5
4.1. Example of a Reputation Service Being Used .................6
5. Terminology and Definitions .....................................7
5.1. Application ................................................7
5.2. Response Set ...............................................7
5.3. Assertions and Ratings .....................................8
5.4. Reputon ....................................................9
6. Information Represented in the Protocol .........................9
7. Information Flow in the Reputation Query Protocol ..............10
8. Privacy Considerations .........................................10
8.1. Data in Transit ...........................................10
8.2. Aggregation ...............................................11
8.3. Collection of Data ........................................11
8.4. Queries Can Reveal Information ............................11
8.5. Compromised Relationships .................................11
9. Security Considerations ........................................12
9.1. Biased Reputation Agents ..................................12
9.2. Malformed Messages ........................................12
9.3. Further Discussion ........................................13
10. Informative References ........................................13
Borenstein & Kucherawy Standards Track [Page 2]
RFC 7070 Reputation Architecture November 2013
1. Introduction
Historically, many Internet protocols have operated between
unauthenticated entities. For example, an email message's author
field (From:) [MAIL] can contain any display name or address and is
not verified by the recipient or other agents along the delivery
path. Similarly, a server that sends email using the Simple Mail
Transfer Protocol [SMTP] trusts that the Domain Name System [DNS] has
led it to the intended receiving server. Both kinds of trust are
easily betrayed, opening the operation to subversion of some kind,
which makes spam, phishing, and other attacks even easier than they
would otherwise be.
In recent years, explicit identity authentication mechanisms have
begun to see wider deployment. For example, the DomainKeys
Identified Mail [DKIM] protocol permits associating a validated
identifier to a message. This association is cryptographically
strong, and is an improvement over the prior state of affairs, but it
Show full document text