REPUTE Working Group                                       N. Borenstein
Internet-Draft                                                  Mimecast
Intended status: Informational                              M. Kucherawy
Expires: June 1, September 6, 2012                                     Cloudmark
                                                       November 29, 2011
                                                        A. Sullivan, Ed.
                                                               Dyn, Inc.
                                                           March 5, 2012

                    A Model for Reputation Interchange
                       draft-ietf-repute-model-00 Reporting


   This document describes the a general model underlying architecture for a set of
   proposals reputation-based
   service and a model for the exchange of reputation information on the Internet,
   and provides a roadmap to the four additional documents that
   collectively define a reputation interchange protocol.  It is
   Internet.  The document roughly to follow follows the recommendations of
   RFC4101 for describing a protocol model.

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
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 1, September 6, 2012.

Copyright Notice

   Copyright (c) 2011 2012 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
   ( 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Document Series . . . .  High-Level Architecture . . . . . . . . . . . . . . . . . . . . 4
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . . . 4 6
     3.1.  Keywords  .  Response Set  . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Vocabulary  . . . . . . . . . . . . . . . . . . . . . . . . 4 6
   4.  Information Represented in the Protocol . a Response Set . . . . . . . . . . . 5 6
   5.  Information Flow in the Protocol  . . . . . . . . . . . . . . . 5 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7
     7.1.  Biased Reputation Agents  . . . . . . . . . . . . . . . . . 6 8
     7.2.  Malformed Messages  . . . . . . . . . . . . . . . . . . . . 7 8
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 7 8
   Appendix A.  Public Discussion  . . . . . . . . . . . . . . . . . . 7 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7 9

1.  Introduction

   Traditionally, most

   Traditionally Internet protocols have taken place operated between
   unauthenticated entities.  For example, when an email message message's author
   field (From) [MAIL] can contain any display name or address and is
   submitted via [SMTP], the server typically trusts the self-
   identification of
   not verified by the sender, and recipient or other agents along the sender delivery
   path.  Similarly, a sending email server using [SMTP] trusts that the
   [DNS] has led it to the right intended receiving server.  Both kinds of
   trust are easily betrayed, leading to opening the door for spam, phishing, and a
   host of other ills.

   In recent years, stronger identity mechanisms have begun to see wider
   deployment.  For example, the [DKIM] protocol permits associating a
   validated identifier to a much higher
   level of trust in the identity of the sending domain of an email message.  While this is a major step
   forward, by itself it does
   little to solve the problem of bad not distinguish between identifiers owned by good
   actors on the Internet. versus bad.  Even if
   you can be sure a message comes from a it is possible to validate the domain called
   "," you don't really know
   name in an author field, such as "," there is
   no basis for knowing whether or not that
   domain it is trustworthy. associated with a good actor
   worthy of trust.  As a practical matter, the both bad actors and good
   adopt basic authentication mechanisms, like DKIM.  In fact, bad
   actors seem tend to
   have adopted DKIM adopt them even more rapidly than the good ones, in the hope actors do
   assuming that some receiving domains receivers will naively confuse a confirmation of identity authentication
   with trustworthiness. identity assessment.  The first merely means that the name is
   being used by its owner or their agent, while the latter makes a
   statement about the quality of the owner.

   The next step, added requirement -- which could can usefully be undertaken only in the
   presence of such stronger identity mechanisms, validation -- is to establish for a mechanism
   by which mutually trusted parties can exchange assessment information
   about other parties.  Such information actors.  A dictionary definition of "reputation" is known as "the
   estimation in which a person or thing is held, especially by the
   community or the public generally", this aggregation of individual
   assessments is called reputation information.

   While the need for reputation information has been most clear in the
   email world, where abuses are commonplace, it is easy to think of
   additional uses for such information.  It could other Internet services
   are coming under attack, indicating a similar need.  A reputation
   mechanism also could be useful in rating the security of web sites,
   the quality of service of an Internet Service Provider (ISP) or
   Application Service Provider (ASP), the customer satisfaction levels
   at e-commerce sites, and even things unrelated to Internet protocols,
   such as rating plumbers, hotels, or books.  Just as human beings
   traditionally rely on the recommendations of trusted parties in the
   physical world, so too they can be expected to make use of such
   reputation information in a variety of applications on the Internet.

   Accordingly, this protocol

   A full trust architecture encompasses a range of actors and
   activities, to enable an end-to-end service for creating and
   consuming trust-related information.  One component of that is designed a
   query mechanism, to facilitate permit retrieval of reputation information that
   facilitates a wide range of reputation applications.  However, not
   all such reputations reputation services will need to convey the same
   information.  Some need only produce a basic rating, while others
   need to provide underlying detail.  This is akin to the difference
   between check approval versus a credit report.

   An overall reckoning of goodness versus badness can be defined
   generically, but specific applications are likely to want to describe
   reputations for multiple attributes; an e-commerce site might be
   rated on price, speed of delivery, customer service, etc., and might
   receive very different ratings on each.  Therefore, this protocol work covered by
   the current effort defines a generic query mechanism and basic format
   for reputation information, while allowing extensions for each

   Omitted from this specification effort is the way means by which an reputation-
   reporting agent that
   wishes to report reputation information regarding something goes about collecting such data. data and the mechanism for
   creating an evaluation.  The protcol mechanism defined in this document and
   its companion documents is here merely about enables
   asking a question and getting an answer; the remainder of the an overall
   service provided by such an a reputation agent is specific to the
   implementation of that service and is out of scope here.

2.  Document Series

   This memo represents  High-Level Architecture

   A reputation mechanism functions as a component of a service, such as
   depicted in Figure 1 of [RFC5863]:

     +------+------+                            +------+------+
     |   Author    |                            |  Recipient  |
     +------+------+                            +------+------+
            |                                          ^
            |                                          |
            |                                   +------+------+
            |                                -->|  Handling   |<--
            |                                -->|   Filter    |<--
            |                                   +-------------+
            |                                          ^
            V                  Responsible             |
     +-------------+           Identifier       +------+------+
     | Responsible |. .       . . . . . . . . .>|  Identity   |
     |  Identity   |  .       .                 |  Assessor   |
     +------+------+  .       .                 +-------------+
            |         V       .                       ^ ^
            V         .       .                       | |
   +------------------.-------.--------------------+  | |
   | +------+------+  . . . > .   +-------------+  |  | |  +-----------+
   | | Identifier  |              | Identifier  +--|--+ +--+ Assessment|
   | |   Signer    +------------->| Validator   |  |       | Databases |
   | +-------------+              +-------------+  |       +-----------+
   |                 DKIM Service                  |

         Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM'

   Here, the base specification, introducing reputation mechanism is shown only as a series query by an
   Identity Assessor, made to Assessment Databases.

   The current work attends specifically to the details of
   others that define the overall service and introduce query
   mechanism.  It defines:

   o  Vocabulary for the initial
   exemplary applications. current work and work of this type

   o  The series is as follows:

   1.  RFCxxxx: types and content of queries that can be supported

   o  The extensible range of response information that can be provided

   o  A Model for Reputation Interchange (this memo)

   2.  RFCxxxx+1: Using query/response protocol

   o  Query/response transport conventions

   The current work targets an extremely simple query/response model
   that can be carried over a variety of mechanisms, including the
   Domain Name System.  (Although not typically thought of as a
   'transport', the DNS provides generic capabilities and can be modeled
   as a mechanism for Reputation Interchange

   3.  RFCxxxx+2: Using UDP transporting queries and responses that have
   nothing to do with addresses.)  Each specification for Reputation Interchange

   4.  RFCxxxx+3: Using the Repute
   transport is independent of any other specification.

        +-----------+         Query              +----------+
        |           +. . . . . . . . . . . . . .>|          |
        |  Client   |                            |  Server  |
        |           <. . . . . . . . . . . . . . +          |
        +-----+-----+         Response           +-------+--+
              |                                     ^    |
              V                                     |    |
        +------+----+                +-----------+  |    | Response
        | Transport |--------------->| Transport |--+    | Set
        +-----------+    DNS for Reputation Interchange

   5.  RFCxxxx+4: Using HTTP/XML for Reputation Interchange

   6.  RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation

   7.  RFCxxxx+6: A         +-----------+       |
                         TCP                             V
                         UDP                      +------------+
                         ...                      | Reputation Vocabulary for Email Property |
                                                  | Database   |

                 Figure 2: Basic Reputation Query Service

3.  Terminology and Definitions

   This section defines terms used in the rest of the document.

3.1.  Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [KEYWORDS].

3.2.  Vocabulary  Response Set

   A "vocabulary" "Response Set" comprises those data that are returned in response
   to a reputation query about a particular entity.  The vocabulary is types of data
   are specific to an application; the data returned in the evaluation
   of email senders would be different than the reputation data returned
   about a movie or a baseball player.


   Response Sets have symbolic names, and these have to be registered
   with IANA to prevent name collisions.  The IANA registries are
   created in a separate memo.

4.  Information Represented in the Protocol a Response Set

   The basic information to be represented in the protocol is fairly
   simple, and MUST include: includes:

   o  the identity of the entity providing the reputation information;

   o  the level of confidence in that identity being genuine;

   o  the identity of the entity being rated;
   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
   provided for specific applications uses of the protocol.  Such service.  The entire collection of
   such information is called the "vocabulary" "Response Set" for that application.
   general query/response protocol defines a syntax for representing such vocabularies,
   Response Sets, but each application will define defines its own vocabulary. Set. Thus, the
   basic information MUST also include: includes:

   o  the name of the application for which the reputation data is being

   For example, a subsequent document will define the separate specification is needed for a reputation
   Response Set for the application an "email-sending-domain" which will to be used to combat spam
   and other abuses of email.  Additional documents define a [MIME] type
   for reputation data, and protocols for exchanging such data.

5.  Information Flow in the Protocol

   The basic reputation data represented in the Response Set could be wrapped into a new [MIME] MIME media type
   [MIME] or a DNS RR, and transported accordingly.  It also can be transported in any number of ways, like any MIME object.
   However, it is anticipated that the typical use
   integral payload of the protocol will
   be a simple request/response.  One purpose-built protocol.  For basic request/
   response scenario, one entity (the Client) will ask a second entity
   (the Server) for reputation data about a third entity, entity (the Target),
   and the second entity will respond with that data.

   It is anticipated that a few applications, at least including the
   email-sending-domain application, will need a small,

   An applications might benefit from an extremely lightweight
   protocol for such
   mechanism, supporting constrained queries and responses, while other applications
   will others
   might need to be able to retrieve support larger and more complex responses.
   For this reason, two subsequent documents define two such protocols,
   one based on DNS queries and a terse representation, and one based on
   [HTTP] queries with an XML representation.

6.  IANA Considerations

   This memo presents no actions for IANA, though later memos in this
   series are likely to do so.

7.  Security Considerations

   This memo introduces an overall protocol model, but no implementation
   details.  As such, the security considerations presented here are
   very high-level.  The detailed analyses of the various specific
   components of the protocol can be found in the subsequent documents
   enumerated in Section 2. that
   instantiate this model.

7.1.  Biased Reputation Agents

   As with [VBR], an agent seeking to make use of a reputation reporting
   service is placing some trust that the service presents an unbiased
   "opinion" of the object about which reputation is being returned.
   The result of trusting the data is, presumably, to guide action taken
   by the reputation client.  It follows, then, that bias in the
   reputation service can adversely affect the client.  Clients,
   therefore, should need to be aware of this possibility and the impact it
   might have.  For example, a biased system returning reputation
   information about a DNS domain found in email messages could result
   in the admission of spam, phishing or malware through a mail gateway.

   Clients might also seek to interact only with reputation services
   that offer some level of transparency into the computation of the
   results they return.  How this might be evaluated, however, is not
   specified here.

   Similarly, a client placing trust in the results returned by such a
   service might suffer if the service itself is compromised, returning
   biased results under the control of an attacker without the knowledge
   of the agency providing reputation service.  This might result from
   an attack on the data being returned at the source, or from a man-in-
   the-middle attack.  Protocols, therefore, should need to be designed so as
   to be as resilient against such attacks as possible.

7.2.  Malformed Messages

   Both clients and servers of reputation systems need to be resistant
   to attacks that involve malformed messages, deliberate or otherwise.
   Failure to do so creates an opportunity for a denial-of-service.

8.  Informative References

   [DKIM]     Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [DNS]      Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [HTTP]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MAIL]     Resnick, P., "Internet Message Format", RFC 5322,
              October 2008.

   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC5863]  Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development,
              Deployment, and Operations", RFC 5863, May 2010.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [VBR]      Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
              Reference", RFC 5518, April 2009.

Appendix A.  Public Discussion

   Public discussion of this suite of memos takes place on the mailing list.  See

Authors' Addresses

   Nathaniel Borenstein
   203 Crescent St., Suite 303
   Waltham, MA  02453

   Phone: +1 781 996 5340
   Murray S. Kucherawy
   128 King St., 2nd Floor
   San Francisco, CA  94107

   Phone: +1 415 946 3800

   Andrew Sullivan (editor)
   Dyn, Inc.
   150 Dow St.
   Manchester, NH  03101