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