One document matched: draft-ietf-repute-model-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc
category="info"
docName="draft-ietf-repute-model-02"
ipr="trust200902">
<front>
<title
abbrev="Reputation Reporting Model"> A Model for Reputation
Reporting </title>
<author
fullname="Nathaniel Borenstein"
initials="N."
surname="Borenstein">
<organization>Mimecast</organization>
<address>
<postal>
<street>203 Crescent St., Suite 303</street>
<city>Waltham</city>
<region>MA</region>
<code>02453</code>
<country>USA</country>
</postal>
<phone>+1 781 996 5340</phone>
<email>nsb@guppylake.com</email>
</address>
</author>
<author
fullname="Murray S. Kucherawy"
initials="M. S."
surname="Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<email>superuser@gmail.com</email>
</address>
</author>
<author
role="editor"
fullname="Andrew Sullivan"
initials="A."
surname="Sullivan">
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>150 Dow St.</street>
<city>Manchester</city>
<region>NH</region>
<code>03101</code>
<country>USA</country>
</postal>
<email>asullivan@dyn.com</email>
</address>
</author>
<date
year="2012"></date>
<area>Applications</area>
<workgroup>REPUTE Working Group</workgroup>
<keyword>domain</keyword>
<keyword>security</keyword>
<keyword>messaging</keyword>
<keyword>dkim</keyword>
<keyword>spf</keyword>
<keyword>authentication</keyword>
<keyword>reputation</keyword>
<abstract>
<t> This document describes a general architecture for a
reputation-based service and a model for the exchange of
reputation information on the Internet. The document roughly
follows the recommendations of RFC4101 for describing a protocol
model. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t> Historically, many Internet protocols have operated between
unauthenticated entities. For example, an email message's author
field (From) <xref
target="MAIL"></xref> can contain any display name or
address and is not verified by the recipient or other agents
along the delivery path. Similarly, a sending email server using <xref
target="SMTP"></xref> trusts that the <xref
target="DNS"></xref> has led it to the intended receiving
server. Both kinds of trust are easily betrayed,
opening the operation to subversion of some kind,
which leads to spam, phishing, and other attacks. </t>
<t> In recent years, stronger identity mechanisms have
begun to see wider deployment. For example, the <xref
target="DKIM"></xref> 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 does not distinguish
between identifiers of good actors and bad. Even
when it is possible to validate the domain name in an
author field (e.g. "trustworthy.example.com" in
"john.doe@trustworthy.example.com") there is no basis for
knowing whether it is associated with a good actor worthy
of trust. As a practical matter, both bad actors and good
adopt basic authentication mechanisms like DKIM. In fact,
bad actors tend to adopt them even more rapidly than the
good actors do in the hope that some receivers will confuse
identity authentication with identity assessment. The
former 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.</t>
<t> The added requirement -- which can usefully be undertaken
only in the presence of such stronger identity validation -- is
for a mechanism by which mutually trusted parties can exchange
assessment information about other actors. For these purposes,
we may usefully define "reputation" as "the estimation in which
an identifiable actor is held, especially by the community or
the Internet public generally". We may call an aggregation of
individual assessments "reputation information."
</t>
<t> While the need for reputation information has been perhaps
most clear in the email world, where abuses are commonplace,
other Internet services are coming under attack and may have a
similar need. For instance, a reputation mechanism 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); customer satisfaction at e-commerce
sites; and even things unrelated to Internet protocols, such as
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. </t>
<t> 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 a
query mechanism, to permit retrieval of reputation information.
Not all such 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. </t>
<t>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, a model defines a generic query mechanism
and basic format for reputation information, but allows
extensions for each application. </t>
<t> Omitted from this model is the means by which an
reputation-reporting agent goes about collecting such data and
the mechanism for creating an evaluation. The mechanism defined
here merely enables asking a question and getting an answer; the
remainder of an overall service provided by such a reputation
agent is specific to the implementation of that service and is
out of scope here. </t>
</section>
<!-- Introduction -->
<section
title="High-Level Architecture">
<t>A reputation mechanism functions as a component of a service,
such as that depicted in Figure 1 of <xref
target="RFC5863"></xref>, reproduced here: <figure
anchor="rfc5683-fig1"
title="RFC5683 'Actors in a Trust Sequence Using DKIM'">
<artwork>
<![CDATA[ +------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+]]>
</artwork>
</figure> Here, the reputation mechanism is shown only as a
query by an Identity Assessor, made to Assessment Databases. </t>
<t>This memo outlines the query and response mechanism. It
provides the following definitions:
<list style="symbols">
<t>Vocabulary for the current work and work of this type;</t>
<t>The types and content of queries that can be
supported;</t>
<t>The extensible range of response information that can be
provided;</t>
<t>A query/response protocol;</t>
<t>Query/response transport conventions.</t>
</list>It provides an extremely simple
query/response model that can be carried over a variety of
transports, including the Domain Name System. (Although not
typically thought of as a 'transport', the DNS provides generic
capabilities and can be thought of as a mechanism for transporting
queries and responses that have nothing to do with addresses.)
Each specification for Repute transport is independent of any
other specification. A diagram of the basic query service is
found in <xref target="query-fig" />.<figure
anchor="query-fig"
title="Basic Reputation Query Service">
<artwork>
<![CDATA[ +-----------+ Query +----------+
| +. . . . . . . . . . . . . .>| |
| Client | | Server |
| <. . . . . . . . . . . . . . + |
+-----+-----+ Response +-------+--+
| ^ |
V | |
+------+----+ +-----------+ | | Response
| Transport |--------------->| Transport |--+ | Set
+-----------+ DNS +-----------+ |
TCP V
UDP +------------+
... | Reputation |
| Database |
+------------+]]>
</artwork>
</figure>
</t>
<t>Both the query and response are application-specific. An
application of the model defines the parameters available to
queries of that type, and also defines the data returned in
response to any query.</t>
</section>
<section
anchor="terms_and_defs"
title="Terminology and Definitions">
<t>This section defines terms used in the rest of the document.</t>
<section
anchor="defs_vocabulary"
title="Response Set">
<t> A "Response Set" comprises those data that are returned in
response to a reputation query about a particular entity.
The 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. </t>
<t> Response Sets have symbolic names, and these have to be
registered with IANA to prevent name collisions. IANA
registries are created in a separate memo. Each definition of
a Response Set needs to define its registry entry.</t>
</section>
<!-- Vocabulary -->
</section>
<!-- Terminology and Definitions -->
<section
anchor="protoinfo"
title="Information Represented in a Response Set">
<t> The basic information to be represented in the protocol is
fairly simple, and includes the following: <list style="symbols">
<t> the identity of the entity providing the reputation
information; </t>
<t> the identity of the entity being rated; </t>
<t> the overall rating score for that entity; </t>
<t> the level of confidence in the accuracy of that rating;
and </t>
<t> the number of data points underlying that score. </t>
</list>
</t>
<t> Beyond this, arbitrary amounts of additional information
might be provided for specific uses of the service. The entire
collection is the Response Set for that application. The
query/response protocol defines a syntax for representing such
Response Sets, but each 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. </t>
<t>Each application requires its own specification of the
Response Set. For example, a specification might be needed for
a reputation Response Set for an "email-sending-domain"; the
Response Set might include information on how often spam was
received from that domain. Additional documents define a <xref
target="MIME"></xref> type for reputation data, and protocols
for exchanging such data. </t>
</section>
<!-- Information Represented in the Protocol -->
<section
anchor="protoflow"
title="Information Flow in the Protocol">
<t> The basic Response Set could be wrapped into a new MIME media
type <xref
target="MIME"></xref> or a DNS RR, and transported
accordingly. It also could be the integral payload of a
purpose-built protocol. For a basic request/response scenario, one
entity (the Client) will ask a second entity (the Server) for
reputation data about a third entity (the Target), and the
second entity will respond with that data. </t>
<t> An applications might benefit from an extremely lightweight
mechanism, supporting constrained queries and responses, while
others might need to support larger and more complex responses.
</t>
</section>
<!-- Information Flow in the Protocol -->
<section
anchor="iana_considerations"
title="IANA Considerations">
<t> This memo presents no actions for IANA. </t>
</section>
<!-- IANA Considerations -->
<section
anchor="priv_considerations"
title="Privacy Considerations">
<t>Some kinds of reputation data are sensitive, and should not
be shared publicly. For applications that have such
sensitivity, it is imperative to pick a transport that will
provide the required authentication and authorization mechanisms
in order to secure communication and deliver responses correctly
according to the proferred credentials. Such transport
questions are the province of the application definitions.</t>
</section>
<section
anchor="sec_considerations"
title="Security Considerations">
<t> 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 the
documents that instantiate this model. </t>
<section
anchor="sec_biased"
title="Biased Reputation Agents">
<t> As with <xref target="VBR"></xref>, 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 need to be aware of this possibility and the effect
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 (by rating the domain name more
favourably than warranted) or could result in the needless
rejection or delay of mail (by rating the domain more
unfavourably than warranted). As a possible mitigation
strategy, clients might seek to interact only with reputation
services that offer some disclosure of the computation methods
for the results they return. Such disclosure and evaluation
is beyond the scope of the present memo. </t>
<t> 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 the
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, need to be designed so as to be
as resilient against such attacks as possible. </t>
</section>
<!-- Biased Reputation Agents -->
<section
anchor="sec_malformed"
title="Malformed Messages">
<t> 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. </t>
</section>
<!-- Malformed Messages -->
</section>
<!-- Security Considerations -->
</middle>
<back>
<references
title="Informative References">
<reference
anchor="MAIL">
<front>
<title>Internet Message Format</title>
<author
fullname="P. Resnick"
initials="P."
surname="Resnick">
<organization></organization>
</author>
<date
month="October"
year="2008"></date>
<abstract>
<t>This document specifies a syntax for text messages
that are sent between computer users, within the
framework of "electronic mail" messages. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="5322"></seriesInfo>
<format
octets="110695"
target="http://www.rfc-editor.org/rfc/rfc5322.txt"
type="TXT"></format>
</reference>
<reference
anchor="RFC5863">
<front>
<title>DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations</title>
<author
fullname="T. Hansen"
initials="T."
surname="Hansen">
<organization></organization>
</author>
<author
fullname="E. Siegel"
initials="E."
surname="Siegel">
<organization></organization>
</author>
<author
fullname="P. Hallam-Baker"
initials="P."
surname="Hallam-Baker">
<organization></organization>
</author>
<author
fullname="D. Crocker"
initials="D."
surname="Crocker">
<organization></organization>
</author>
<date
month="May"
year="2010"></date>
<abstract>
<t>DomainKeys Identified Mail (DKIM) allows an
organization to claim responsibility for
transmitting a message, in a way that can be
validated by a recipient. The organization can be
the author's, the originating sending site, an
intermediary, or one of their agents. A message can
contain multiple signatures, from the same or
different organizations involved with the message.
DKIM defines a domain-level digital signature
authentication framework for email, using public key
cryptography and using the domain name service as
its key server technology. This permits verification
of a responsible organization, as well as the
integrity of the message content. DKIM will also
provide a mechanism that permits potential email
signers to publish information about their email
signing practices; this will permit email receivers
to make additional assessments about messages.
DKIM's authentication of email identity can assist
in the global control of "spam" and "phishing". This
document provides implementation, deployment,
operational, and migration considerations for DKIM.
This document is not an Internet Standards Track
specification; it is published for informational
purposes.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="5863"></seriesInfo>
<format
octets="126915"
target="http://www.rfc-editor.org/rfc/rfc5863.txt"
type="TXT"></format>
</reference>
<reference
anchor="DKIM">
<front>
<title> DomainKeys Identified Mail (DKIM) Signatures </title>
<author
fullname="E. Allman"
initials="E."
surname="Allman">
<organization></organization>
</author>
<author
fullname="J. Callas"
initials="J."
surname="Callas">
<organization></organization>
</author>
<author
fullname="M. Delany"
initials="M."
surname="Delany">
<organization></organization>
</author>
<author
fullname="M. Libbey"
initials="M."
surname="Libbey">
<organization></organization>
</author>
<author
fullname="J. Fenton"
initials="J."
surname="Fenton">
<organization></organization>
</author>
<author
fullname="M. Thomas"
initials="M."
surname="Thomas">
<organization></organization>
</author>
<date
month="May"
year="2007"></date>
</front>
<seriesInfo
name="RFC"
value="4871"></seriesInfo>
</reference>
<reference
anchor="DNS">
<front>
<title abbrev="Domain Implementation and
Specification"> Domain names - implementation and
specification </title>
<author
fullname="P. Mockapetris"
initials="P."
surname="Mockapetris">
<organization>USC/ISI</organization>
</author>
<date
day="1"
month="November"
year="1987"></date>
</front>
<seriesInfo
name="STD"
value="13"></seriesInfo>
<seriesInfo
name="RFC"
value="1035"></seriesInfo>
</reference>
<!-- these never get used.
<reference
anchor="HTTP">
<front>
<title> Hypertext Transfer Protocol -- HTTP/1.1 </title>
<author
fullname="R. Fielding"
initials="R."
surname="Fielding">
<organization> UC Irvine </organization>
</author>
<author
fullname="J. Gettys"
initials="J."
surname="Gettys">
<organization> Compaq/W3C </organization>
</author>
<author
fullname="J. Mogul"
initials="J."
surname="Mogul">
<organization> Compaq </organization>
</author>
<author
fullname="H. Frystyk"
initials="H."
surname="Frystyk">
<organization> W3C/MIT </organization>
</author>
<author
fullname="L. Masinter"
initials="L."
surname="Masinter">
<organization> Xerox </organization>
</author>
<author
fullname="P. Leach"
initials="P."
surname="Leach">
<organization> Microsoft </organization>
</author>
<author
fullname="T. Berners-Lee"
initials="T."
surname="Berners-Lee">
<organization> W3C/MIT </organization>
</author>
<date
month="June"
year="1999"></date>
</front>
<seriesInfo
name="RFC"
value="2616"></seriesInfo>
</reference>
<reference
anchor="KEYWORDS">
<front>
<title
abbrev="RFC Key Words">Key words for use in RFCs to
Indicate Requirement Levels</title>
<author
fullname="Scott Bradner"
initials="S."
surname="Bradner">
<organization>Harvard University</organization>
</author>
<date
month="March"
year="1997"></date>
</front>
<seriesInfo
name="BCP"
value="14"></seriesInfo>
<seriesInfo
name="RFC"
value="2119"></seriesInfo>
</reference>
-->
<reference
anchor="MIME">
<front>
<title
abbrev="Internet Message Bodies"> Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies </title>
<author
fullname="Ned Freed"
initials="N."
surname="Freed">
<organization> Innosoft International, Inc.
</organization>
</author>
<author
fullname="Nathaniel S. Borenstein"
initials="N.S."
surname="Borenstein">
<organization> First Virtual Holdings </organization>
</author>
<date
month="November"
year="1996"></date>
</front>
<seriesInfo
name="RFC"
value="2045"></seriesInfo>
</reference>
<reference
anchor="SMTP">
<front>
<title>Simple Mail Transfer Protocol</title>
<author
fullname="J. Klensin"
initials="J."
surname="Klensin">
<organization></organization>
</author>
<date
month="October"
year="2008"></date>
</front>
<seriesInfo
name="RFC"
value="5321"></seriesInfo>
</reference>
<reference
anchor="VBR">
<front>
<title> Vouch By Reference </title>
<author
fullname="P. Hoffman"
initials="P."
surname="Hoffman">
<organization> Domain Assurance Council </organization>
</author>
<author
fullname="J. Levine"
initials="J."
surname="Levine">
<organization> Domain Assurance Council </organization>
</author>
<author
fullname="A. Hathcock"
initials="A."
surname="Hathcock">
<organization> Alt-N Technologies </organization>
</author>
<date
month="April"
year="2009"></date>
</front>
<seriesInfo
name="RFC"
value="5518"></seriesInfo>
</reference>
</references>
<section
anchor="public"
title="Public Discussion">
<t> Public discussion of this suite of memos takes place on the
domainrep@ietf.org mailing list. See
https://www.ietf.org/mailman/listinfo/domainrep. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:36:26 |