Mimecast

203 Crescent St., Suite 303 Waltham MA 02453 USA +1 781 996 5340 nsb@guppylake.com

270 Upland Drive San Francisco CA 94127 USA superuser@gmail.com

Applications REPUTE Working Group reputation domain security messaging dkim spf authentication This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

This document defines a data object for use when answering a reputation query. It also defines a media type to carry the response set data when using a transport method that follows the media type framework, such as the query method based on the HyperText Transfer Protocol (HTTP) defined in . Any future query methods that might be developed are expected to use the same data object. Also included is the specification for an IANA registry to contain definitions and symbolic names for known reputation applications and corresponding response sets.

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

A "reputon" is a single independent object containing reputation information. A particular query about a subject of interest will receive one or more reputons in response, depending on the nature of the data collected and reported by the server.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Other terms of importance in this document are defined in , the base document in this document series.

The meta-format selected for the representation of a reputon is JavaScript Object Notation (JSON), defined in . Accordingly, a new media type, "application/reputon+json", is defined for the JSON representation of reputational data, typically in response to a client making a request for such data about some subject. This media type takes no parameters. The body of the media type consists of a JSON document that contains the reputation information requested. A detailed description of the expected structure of the reply is provided below. The media type comprises a single member indicating the name of the application context (see Section 5.1 of ) in which the reputational data are being returned. The application name refers to a registration as described in , which defines the valid assertions and any extensions that might also be valid (i.e., the response set) for that application.

The key pieces of data found in a reputon for all reputation applications are defined as follows: The identity of the entity aggregating, computing, and providing the reputation information, typically expressed as a DNS domain name. A key word indicating the specific assertion or claim being rated. The identity of the entity being rated. The nature of this field is application specific; it could be domain names, email addresses, driver's license numbers, or anything that uniquely identifies the entity being rated. Documents that define specific reputation applications are required to define syntax and semantics for this field. The overall rating score for that entity, expressed as a floating-point number between 0.0 and 1.0 inclusive. See for discussion. The following are OPTIONAL for all applications, to be used in contexts where they are appropriate: the level of certainty the reputation provider has that the value presented is appropriate, expressed as a floating-point number between 0.0 and 1.0 inclusive. An indication of what the reputation provider would normally expect as a rating for the subject. This allows the client to note that the current rating is or is not in line with expectations. The number of data points used to compute the rating, possibly an approximation. Expressed as an unsigned 64-bit integer. Consumers can assume that the count refers to distinct data points rather than a count of aggregations (for example, individual votes rather than aggregated vote counts) unless it is specified out-of-band that some other interpretation is more appropriate. The units are deliberately not normatively specified, since not all reputation service providers will collect data the same way. A timestamp indicating when this value was generated. Expressed as the number of seconds since January 1, 1970 00:00 UTC. A timestamp indicating a time beyond which the score reported is likely not to be valid. Expressed as the number of seconds since January 1, 1970 00:00 UTC. See for discussion. A particular application that registers itself with IANA (per , below) can define additional application-specific attribute/value pairs beyond these standard ones. An application service provider might operate with an enhanced form of common services, which might in turn prompt development and reporting of specialized reputation information. The details of the enhancements and specialized information are beyond the scope of this document, except that the underlying JSON syntax is extensible for encoding such provider-specific information.

The score presented as the value in the rating attribute appears as a floating-point value between 0.0 and 1.0 inclusive. The intent is that the definition of an assertion within an application will declare what the anchor values 0.0 and 1.0 specifically mean. Generally speaking, 1.0 implies full agreement with the assertion, while 0.0 indicates no support for the assertion. The definition will also specify the type of scale in use when generating scores, to which all reputation service providers for that application space must adhere. Further discussion can be found in .

A reputon can contain an "expires" field indicating a timestamp after which the client SHOULD NOT use the rating it contains and SHOULD issue a new query. This specification does not mandate any caching of ratings on the part of the client, but there are obvious operational benefits to doing so. In the context of reputation, a cached (and hence, stale) rating can cause desirable traffic to be identified as undesirable, or vice versa. Reputation data is typically most volatile when the subject of the reputation is young. Accordingly, if a service chooses to include expiration timestamps as part a reply, these values SHOULD be lower for subjects about which little data has been collected.

A reputon expressed in JSON is a set of key-value pairs, where the keys are the names of particular attributes that comprise a reputon (as listed above, or as provided with specific applications), and values are the content associated with those keys. The set of keys that make up a reputon within a given application are known as that application's "response set". A reputon object typically contains a reply corresponding to the assertion for which a client made a specific request. For example, a client asking for assertion "sends-spam" about domain "example.com" would expect a reply consisting of a reputon making a "sends-spam" assertion about "example.com" and nothing more. If a client makes a request about a subject but does not specify an assertion of interest, the server can return reputons about any assertion for which it has data; in effect, the client has asked for any available information about the subject. A client that receives an irrelevant reputon simply ignores it. An empty reputon is an acknowledgement by the server that the request has been received, and serves as a positive indication that the server does not have the information requested. This is semantically equivalent to returning a reputon with a "sample-size" of zero.

defines the structure of JSON objects and arrays using a set of primitive elements. Those elements will be used to describe the JSON structure of a reputation object.

a JSON object, defined in Section 2.2 of a member of a JSON object, defined in Section 2.2 of the name of a MEMBER, defined as a "string" in Section 2.2 of the value of a MEMBER, defined as a "value" in Section 2.2 of an array, defined in Section 2.3 of an element of an ARRAY, defined in Section 2.3 of a "number" as defined in Section 2.4 of an "integer" as defined in Section 2.4 of a "string" as defined in Section 2.5 of

Using the above terms for the JSON structures, the syntax of a reputation object is defined as follows: an OBJECT containing a MEMBER reputation-context and a MEMBER reputon-list a MEMBER with MEMBER-NAME "application" and MEMBER-VALUE a STRING (see ) a MEMBER with MEMBER-NAME "reputons" and MEMBER-VALUE a reputon-array an ARRAY, where each ARRAY-VALUE is a reputon an OBJECT, where each MEMBER is a reputon-element one of the following, defined below: rater-value, assertion-value, rated-value, rating-value, conf-value, normal-value, sample-value, gen-value, expire-value, ext-value; note the following: The order of reputon-element members is not significant. A specific reputon-element MUST NOT appear more than once. rater-value, assertion-value, rated-value, and rating-value are REQUIRED. a MEMBER with MEMBER-NAME "rater" and MEMBER-VALUE a STRING (see "rater" in ) a MEMBER with MEMBER-NAME "assertion" and MEMBER-VALUE a STRING (see "assertion" in ) a MEMBER with MEMBER-NAME "rated" and MEMBER-VALUE a STRING (see "rated" in ) a MEMBER with MEMBER-NAME "rating" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "rating" in ); the number SHOULD NOT not have more than three decimal places of precision a MEMBER with MEMBER-NAME "confidence" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "confidence" in ); the number SHOULD NOT not have more than three decimal places of precision a MEMBER with MEMBER-NAME "normal-rating" and MEMBER-VALUE a NUMBER between 0.0 and 1.0 inclusive (see "normal" in ); the number SHOULD NOT not have more than three decimal places of precision a MEMBER with MEMBER-NAME "sample-size" and MEMBER-VALUE a non-negative INTEGER (see "sample-size" in "normal" in ) a MEMBER with MEMBER-NAME "generated" and MEMBER-VALUE a non-negative INTEGER (see "generated" in ) a MEMBER with MEMBER-NAME "expires" and MEMBER-VALUE a non-negative INTEGER (see "expires" in ) a MEMBER, for extension purposes; MEMBER-NAME and MEMBER-VALUE will be defined in separate application registrations

The following simple example:

Content-Type: application/reputon+json { "application": "baseball", "reputons": [ { "rater": "RatingsRUs.example.com", "assertion": "is-good", "rated": "Alex Rodriguez", "rating": 0.99, "sample-size": 50000 } ] }

...indicates to the client that "RatingsRUs.example.com" consolidated 50000 data points (perhaps from everyone in Yankee Stadium) and concluded that Alex Rodriguez is very, very good (0.99) at something. It doesn't tell us what he's good at, and while it might be playing baseball, it could just as well be paying his taxes on time. A more sophisticated usage would define a baseball application with a response set of specific assertions, so that this example:

Content-Type: application/reputon+json { "application": "baseball", "reputons:" [ { "rater": "baseball-reference.example.com", "assertion": "hits-for-power", "rated": "Alex Rodriguez", "rating": 0.99, "sample-size": 50000 } ] }

...would indicate that 50000 fans polled by the entity baseball-reference.example.com rate Alex Rodriguez very highly in hitting for power, whereas this example:

Content-Type: application/reputon+json { "application": "baseball", "reputons": [ { "rater": "baseball-reference.example.com", "assertion": "strong-hitter", "rated": "Alex Rodriguez", "rating": 0.4, "confidence": 0.2, "sample-size": 50000 } ] }

...would indicate that a similar poll indicated a somewhat weak consensus that Alex Rodriguez tends to fail in critical batting situations during baseball games. The following is an example reputon generated using this schema, including the media type definition line that identifies a specific reputation application context. Here, reputation agent "rep.example.net" is asserting within the context of the "email-id" application (see ) that "example.com" appears to be associated with spam 1.2% of the time, based on just short of 17 million messages analyzed or reported to date. The "email-id" application has declared the extension key "email-id-identity" to indicate how the subject identifier was used in the observed data, establishing some more-specific semantics for the "rating" value. In this case, the extension is used to show the identity "example.com", the subject of the query, is extracted from the analyzed messages using the DomainKeys Identified Mail "d=" parameter for messages where signatures validate. The reputation agent is 95% confident of this result. A second reputon is also present indicating similar information for the same domain as it is used in the context of Sender Policy Framework evaluations. (See for details about the registered email identifiers application.)

Content-Type: application/reputon+json { "application": "email-id", "reputons": [ { "rater": "rep.example.net", "assertion": "spam", "identity": "dkim", "rated": "example.com", "confidence": 0.95, "rating": 0.012, "sample-size": 16938213, "updated": 1317795852 }, { "rater": "rep.example.net", "assertion": "spam", "identity": "spf", "rated": "example.com", "confidence": 0.98, "rating": 0.023, "sample-size": 16938213, "updated": 1317795852 } ] }

This document presents two actions for IANA -- namely, the creation of the new media type "application/reputon+json" and the creation of a registry for reputation application types. Another document in this series creates an initial registry entry for the latter.

This section provides the media type registration application from for processing by IANA. media-types@iana.org Registration of media type application/reputon+json application reputon+json none none "7bit" encoding is sufficient and is used to maintain readability when viewed by non-MIME mail readers. See of [RFC7071]. Implementers may encounter "app" values, attribute/value pairs, or response set items that they do not support, which are to be ignored. [RFC7071] Any application that wishes to query a service that provides reputation data using the form defined in . The example application is one that provides reputation data about DNS domain names and other identifiers found in email messages. N/A The value of the "app" parameter is registered with IANA. N/A N/A N/A N/A Murray S. Kucherawy <superuser@gmail.com> COMMON N/A Nathaniel Borenstein Murray S. Kucherawy IESG no

IANA has created the "Reputation Applications" registry. This registry contains names of applications used with the application/reputon+json media type (and other media types that carry reputons), as defined by this document. New registrations or updates are published in accordance with either the "IETF Review" or "Specification Required" guidelines as described in . New registrations and updates are to contain the following information: Symbolic name of the application being registered or updated. Valid names conform to the ABNF construction "token" as defined in Multipurpose Internet Mail Extensions (MIME) Part One Short description of the application (i.e., the class of entity about which it reports reputation data) The document in which the application is defined New or updated status, which is to be one of: The application is in current use The application is in current use but its use is discouraged The application is no longer in current use A specification for an application space needs to be specific and clear enough to allow interoperability, and include at least the following details: The application's symbolic name, as it appears in the registration (see above) A description of the subject of a query within this reputation, and a legal syntax for the same An optional table of query parameters that are specific to this application; each table entry must include: Name of the query parameter (as above) A short description of the purpose of this parameter A reference to a description of valid syntax for the parameter's value "yes" if the parameter is mandatory; "no" otherwise A list of one or more assertions registered within this application; each table entry is to include: Name of the assertion A short description of the assertion, with specific meanings for values of 0.0 and 1.0 A short description of the scale used in computing the value (see of this document) An optional list of one or more response set extension keys for use within this application; each table entry is to include: Name of the extension key A short description of the key's intended meaning A description of valid values that can appear associated with the key The names of attributes registered should be prefixed by the name of the application itself (e.g., the "foo" application registering a "bar" attribute should call it "foo-bar") to avoid namespace collisions. For registrations qualifying under "Specification Required" rules, the Designated Expert should confirm the document meets the minima described above and otherwise looks generally acceptable, and then approve the registration.

This document is primarily an IANA action registering a media type. It does not describe a new protocol that might introduce security considerations. Discussion of the security and operational impacts of using reputation services in general can be found throughout .

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. 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 RFC4101 for describing a protocol model. This document defines a mechanism to conduct queries for reputation information over the Hypertext Transfer Protocol using JSON as the payload meta-format. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</t><t> This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] The use of reputation systems is has become a common tool in many applications that seek to apply collected intelligence about traffic sources. Often this is done because it is common or even expected operator practice. It is therefore important to be aware of a number of considerations for both operators and consumers of the data. This document includes a collection of the best advice available regarding providers and consumers of reputation data, based on experience to date. Much of this is based on experience with email reputation systems, but the concepts are generally applicable. This document defines a response set for describing assertions a reputation service provider can make about email identifers, for use in generating reputons. Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community.

The authors wish to acknowledge the contributions of the following to this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, Simon Hunt, John Levine, David F. Skoll, and Mykyta Yevstifeyev.