One document matched: draft-ietf-repute-model-01.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-01"
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>
<phone>+1 415 946 3800</phone>
<email>msk@cloudmark.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> Traditionally 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
door for spam, phishing, and a host of other ills. </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. While this is a major step
forward, it does not distinguish between identifiers owned by
good actors versus bad. Even if it is possible to validate the
domain name in an author field, such as
"@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 assuming
that some receivers will confuse identity authentication with
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.</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. A dictionary
definition of "reputation" is "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.
<!-- {{ Does the dictionary definition need a citation? }} -->
</t>
<t> While the need for reputation information has been most clear in
the email world, where abuses are commonplace, 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. </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
that facilitates a wide range of reputation applications.
However, 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, work covered by the current effort defines a generic
query mechanism and basic format for reputation information,
while allowing extensions for each application. </t>
<t> Omitted from this effort 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 depicted in Figure 1 of <xref
target="RFC5863"></xref>: <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> The current work attends specifically to the details of the
query mechanism. It defines: <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> 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 transporting
queries and responses that have nothing to do with addresses.)
Each specification for Repute transport is independent of any
other specification. <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>
</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. The IANA
registries are created in a separate memo. </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: <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 of such information is called the "Response Set" for
that application. The query/response protocol defines a syntax
for representing such Response Sets, but each application
defines its own Set. Thus, the basic information also includes: <list
style="symbols">
<t> the name of the application for which the reputation
data is being expressed. </t>
</list>
</t>
<t> For example, a separate specification is needed for a reputation
Response Set for an "email-sending-domain" to be used to combat
spam and other abuses of email. 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 can be the integral payload of a
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 (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, though later memos in
this series are likely to do so. </t>
</section>
<!-- IANA Considerations -->
<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
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. </t>
<t> 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. </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
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>
<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:28 |