Network Working Group P. Hoffman Internet-Draft J. Levine Intended status: Standards Track Domain Assurance Council Expires: August 22, 2008 February 19, 2008 Format for Domain Reputation Data draft-hoffman-dac-domainrepdata-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes two formats for reputation data for domains. The smaller format contains data that is expected to be used in real- time receiver decisions, while the larger format is used for more complete data that is appropriate for off-line decision making. Hoffman & Levine Expires August 22, 2008 [Page 1] Internet-Draft Domain Reputation February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Smaller Format for Responses . . . . . . . . . . . . . . . . . 3 3. Larger Format for Responses . . . . . . . . . . . . . . . . . . 4 4. Examples of Reputation Records . . . . . . . . . . . . . . . . 5 5. RELAX NG schema . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 Appendix B. Changes between versions . . . . . . . . . . . . . . . 6 B.1. Differenes between -00 and -01 . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Hoffman & Levine Expires August 22, 2008 [Page 2] Internet-Draft Domain Reputation February 2008 1. Introduction Providers of domain reputation want to be able to publish many types of reputation data. Among these are: o A score along some scale, plus an indication of the confidence in that score o Data about the domain's owner such as their name, how long they have been in business, where they are located, the type of business they are in, they type of mail they send, and so on o Recent mailing statistics for the domain o Number and types of complaints about the domain o Innumerable others There are many models for the ways domain reputation information could be distributed. Some providers might give some data away freely while charging for other data; some providers would give away the data in exchange for valuable feedback from the recipient about the domains; some providers would sell the reputation data to the owner of the domain and certain mail receivers; and so on. There are also many models for the ways the domain reputation data would be used by mail senders and receivers. SMTP servers could use a score of the likelihood that they would want to receive mail from a particular domain, and they might be interested in the type of business of the sender for mixing into their decision on how to deliver the mail (banks might be more likely to be delivered to the inbox, auto dealers to the spam folder). ISPs might buy reputation data in bulk to help create their own in-house scoring systems. This document describes two formats for reputation data for domains. The smaller format contains data that is expected to be used in real- time receiver decisions, while the larger format is used for more complete data that is appropriate for off-line decision making. DAC will later define protocols for retrieving the reputation data; these are likely to be based on DNS queries and responses. [[ The intended status of this document is an Informational RFC that will be submitted as an independent submission to the RFC Editor. ]] 2. Smaller Format for Responses The smaller response format is plain text with single spaces as separators. An explicit goal is that the response can be parsed without XML parsers (which are rare on SMTP servers). The format for a small response is: Hoffman & Levine Expires August 22, 2008 [Page 3] Internet-Draft Domain Reputation February 2008 All fields, and the single space between each, are required. o version -- a text string; for the first version of the protocol, it is "1". o score -- the likelihood that a recipient who trusts the reputation provider would want to receive mail from the domain. The value specifies a number between 0 and 99 inclusive that is the relative score of the the domain. o confidence -- the confidence of the reputation provider in the score. It is a number between 0 and 99 inclusive with 50 meaning "average confidence". o SIC -- the numeric NAICS code of the business associated with the domain. The value is the numeric code. The most recent list of NAICS codes can be found at [NAICS-CODES]. An example of such a record might be: 1 72 99 52213 3. Larger Format for Responses The larger response format is XML. The XML overhead for this format is approximately 100 bytes, which leaves plenty of room within even a 512-byte UDP DNS response for simple information. In the inevitable cases where the answer is too big for one UDP packet, there is a simple fall-back to TCP, although the number of larger-format queries that have that much data is probably limited. A set of common elements is defined in the namespace "http://domain-assurance.org/rep-3". A reputation provider can use their own XML namespace or other common XML namespaces for elements not defined in the DAC namespace. DAC-defined elements have very short names in order to maximize the number that can fit in a single UDP packet. Every element is optional. Also, every element also has an optional c attribute whose value is a number between 0 and 99 inclusive that is the confidence of the reputation provider in the information in the element. If the c attribute is not given, the default value is 50, meaning "average confidence". It is expected that the c attribute will not be used often. The general defined elements are listed here. Hoffman & Levine Expires August 22, 2008 [Page 4] Internet-Draft Domain Reputation February 2008 o sc -- Score, the likelihood that a recipient who trusts the reputation provider would want to receive mail from the domain. The value specifies a number between 0 and 99 inclusive that is the relative score of the the domain. o in -- Industry, the numeric NAICS code of the business associated with the domain. The value is the numeric code. The most recent list of NAICS codes can be found at [NAICS-CODES]. o na -- Name, the true name of the business associated with the domain. o st1, st2, ci, pr, co, pc -- Postal address elements of the business associated with the domain: street address 1, street address 2, city, state or province, country, postal code. The country should be given as the two-letter ISO 3166 code. o te -- Telephone, the telephone number of the business associated with the domain. The value holds the text string that is the telephone number; spaces, periods, and hyphens are explicitly allowed. The value should include the country code prefaced with a "+". 4. Examples of Reputation Records An example using just the defined elements might be: 72 52213 Example Company LLC 127 Typical Street, Suite 500 AnytownCAUS95782-4410 +1 672.487.0091 An example including provider-defined elements might be: 72 a1892c25e959bd7a87161724dfec8c6d Hoffman & Levine Expires August 22, 2008 [Page 5] Internet-Draft Domain Reputation February 2008 5. RELAX NG schema grammar { c-att = attribute c { xsd:integer } start = element rep { default namespace ='http://domain-assurance.org/rep-3' element sc { c-att?, xsd:integer }?, element in { c-att?, xsd:integer }?, element na { c-att?, text }?, element st1 { c-att?, text }?, element st2 { c-att?, text }?, element ci { c-att?, text }?, element pr { c-att?, text }?, element co { c-att?, text }?, element pc { c-att?, text }?, element te { c-att?, text }?, }} 6. Security Considerations There are no security considerations for publishing reputation information about domain names. 7. Informative References [NAICS-CODES] U.S. Census Bureau, "2002 NAICS Codes and Titles", 2002, . Appendix A. Acknowledgements Many members of the Domain Assurance Council contributed to the design of the protocol and the wording of this document. Appendix B. Changes between versions [[ This whole section will be removed before being published as an RFC. ]] B.1. Differenes between -00 and -01 Minor editorial revisions. Added the intended status of the document. Hoffman & Levine Expires August 22, 2008 [Page 6] Internet-Draft Domain Reputation February 2008 Authors' Addresses Paul Hoffman Domain Assurance Council Email: paul.hoffman@domain-assurance.org John Levine Domain Assurance Council Email: john.levine@domain-assurance.org Hoffman & Levine Expires August 22, 2008 [Page 7] Internet-Draft Domain Reputation February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hoffman & Levine Expires August 22, 2008 [Page 8]