ASRG Working Group Internet Draft P. Hallam-Baker Document: draft-hallambaker-accredit-00.txt VeriSign Inc. Expires: September 2004 July 2004 DNS Publication Accreditation Data Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. Abstract This document describes a mechanism that may be used to publish accreditation data associated with email senders authenticated by means of SPF or CallerID. An accreditation is a description by a third party that describes an email sender in some way that helps the recipient estimate the likelihood that a message authenticated as being originated by the sender is spam. Conventions used in this 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 [1]. Hallam-Baker Expires - January !Undefined Bookmark, SAVEDATE[Page 1] DNS Publication of Accreditation Data July 2004 Table of Contents 1. Introduction...................................................2 1.1 Accreditation Authorities..................................3 1.2 Accountability of Accreditation Authorities................3 1.3 Practices Considerations...................................4 1.4 Accreditation Statements...................................4 1.5 Notification of Accreditation Existence....................5 1.6 Publication of Accreditation Statements....................5 1.7 Accreditation Authority Description Data...................5 1.8 Interpretation of Accreditation Statements.................5 2. Policy Notification Bindings...................................6 2.1 SPF........................................................6 2.2 CallerID...................................................6 3. DNS Publication of Accreditation Statements....................7 3.1 Accreditation Authority Description Record.................7 Element Accredit...............................................7 Element Collection.............................................8 Element Protocol...............................................8 Element Entry..................................................9 3.2 Sender Recipient A Record..................................9 3.3 Other Sender Recipient Records............................10 4. Filter Interpretation Guidelines..............................10 4.1 Establishing Provider Reputation..........................10 4.2 Combining Accreditations..................................11 5. Security Considerations.......................................11 5.1 Unauthenticated or Wrongly Authenticated Sender...........11 5.2 Untrustworthy Accreditation Provider......................11 5.3 DNS Security Issues.......................................11 References.......................................................12 Author's Addresses...............................................12 1. Introduction This specification describes a mechanism that may be used to publish accreditation data associated with email senders authenticated by means of SPF [2] or CallerID [3]. We note that the MARID group is currently considering a joint proposal. An accreditation is a statement by a third party that the recipient of an email may use to estimate the probability that the sender is a spammer. The architecture of this proposal generalizes existing industry practice with respect to publication of DNS blacklists according to the method proposed by Vixie [4]. Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 2] DNS Publication of Accreditation Data July 2004 Unlike the earlier proposal the mechanism described in this document MAY be used by accreditation agencies that only report accreditation data for some email senders without unnecessary queries for parties that are not covered. It is thus better suited to applications where the accreditation authority is reporting positive accreditation data concerning a small group of trusted senders. 1.1 Accreditation Authorities An Accreditation Authority is a third party that is responsible for making statements that describe email senders. Accreditation Authorities MAY be restricted or unrestricted. A restricted accreditation authority only publishes statements that relate to a restricted number of email senders. An unrestricted accreditation authority publishes statements for all email senders. An accreditation authority may take additional measures to improve the value of their accreditation, for example bringing civil suits against parties that breach the undertakings given. 1.2 Accountability of Accreditation Authorities Experience of anti-spam blacklists has shown that those who attempt to provide accountability must in turn be accountable. There is no difficulty in ensuring that accreditation providers are accountable to email recipients. An accreditation authority that provides incorrect accreditation will soon be ignored. The value of an accreditation may be measured empirically by measuring the proportion of the message sent bearing a particular accreditation that are determined to be spam (e.g. through user reports). If the ability to measure the value of an accreditation agency is to be of use to the recipient it must be possible for new accreditation providers to offer their services without artificial barriers to entry such as magic lists of æapprovedÆ providers. One way to avoid this problem is to allow email senders to specify the accreditation providers they favor. Although it is unlikely that any individual would specify an accreditation provider that gave them a bad rating, an accreditation service that had established a sufficiently high reputation on the basis of its positive accreditations could offer to supply negative ratings. Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 3] DNS Publication of Accreditation Data July 2004 This mechanism offers substantial advantages over the current situation in which maintainers of anti-spam blacklists are effectively unaccountable to any party. Accreditation services are held accountable to both senders and receivers. 1.3 Practices Considerations As a trusted third party the actions of an Accreditation Authority are raise numerous legal issues. These issues are outside the scope of this document and have been considered at length in the context of PKI Certification Authorities. 1.4 Accreditation Statements At present a large number of different parties act as Accreditation Authorities with respect to sending of email. Blacklists attempt to identify bad faith actors while whitelists look to identify good faith actors. Whitelist accreditations may involve a simple promise not to spam or a promise that is backed up by some form of penalty such as the forfeiture of a bond or the publication of negative reputation data. Despite the wide variety in the types of data Accreditation Authorities provide the inferences that anti-spam filtering techniques attempt to draw are the same, is a particular item of email likely or unlikely to be spam. For this reason we leave the details of the means by which accreditation statements are compiled to the Accreditation Authority. An accreditation authority MAY publish any form of accreditation statement they choose. The following types of statement are likely to be of greatest utility. Identity Accreditation The email sender has provided a real world identity and a physical address at which legal process can be served and this information has been authenticated by means of some trustworthy process. Undertaking Accreditation In addition to meeting the identity accreditation requirements, the email sender has undertaken to comply with a specified email sending policy. Performance Accreditation Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 4] DNS Publication of Accreditation Data July 2004 The email sender has been determined to have met the requirements of an email sending policy. If the email sender has previously undertaken to comply with the email sending policy in question the accreditation is a Compliance Accreditation. 1.5 Notification of Accreditation Existence A sender MAY notify recipients of the existence of an accreditation statement by means of a policy notification mechanism such as CallerID or SPF. The use of the policy notification mechanism allows senders to bring the existence of a new accreditation mechanism to the attention of an adaptive filtering mechanism. Such a filter would determine the reputation of an accreditation agency empirically by measuring the accuracy with which the agency categorizes senders. Senders are unlikely to advertise the existence of unfavorable accreditation statements unless they believe that there is a high probability that the recipient will not verify the statement. Accreditation authorities that publish unfavorable data concerning a subject need to inform recipients that the accreditation service is 'open' and MAY be consulted to obtain information even if the sender does not list the service as an accreditor. This information SHOULD be provided by means of an Accreditation Authority Description record. 1.6 Publication of Accreditation Statements Accreditation statements are published by means of an extension of the existing mechanism used for publication of anti-spam blacklists via DNS. An accreditation statement is published by means of the DNS A record. To avoid collisions with other uses of the DNS addresses in the 127.x.x.x loopback address range are typically used. 1.7 Accreditation Authority Description Data The domain prefix specified for an accreditation service MAY contain a TXT record with the prefix _accredit that contains a URL that points to an XML document that describes the use of the particular accreditation service. 1.8 Interpretation of Accreditation Statements Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 5] DNS Publication of Accreditation Data July 2004 Email recipients MAY interpret Accreditation Statements in any fashion they choose, including regarding an Accreditation Statement as a negative indicator. The reputation of the Accreditation Authority MUST be considered suspect until proven reliable. 2. Policy Notification Bindings Policy notification bindings are specified for SPF and CallerID. Other notification bindings MAY be specified in the specification document describing the policy notification mechanism where they are to be used. Note that the policy bindings are not exclusive. A sender MAY use both the SPF and CallerID methods of specifying the email policy. 2.1 SPF A sender MAY use the SPF modifier 'accredit' to notify recipients of the existence of an accreditation record concerning the sender domain. accredit= The value specifies the location of the accreditation service. If the value of is 'accredit.test' and the sender domain is 'example.com': The accreditation authority description record for the domain will be the TXT record associated with the DNS label _accredit.accredit.test. If the DNS protocol is used to publish the accreditation data itself, the accreditation records for the domain 'example.com' will be associated with the DNS label example.com._accredit.accredit.test. A sender MAY specify multiple accreditation records. 2.2 CallerID A sender MAY use the æPer domain indication of email transmission policyÆ specified in the CSRI architecture [5]. The accreditation domain is specified by means of the element as specified in Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 6] DNS Publication of Accreditation Data July 2004 that document. The equivalent code for the SPF example above would be: accredit.test 3. DNS Publication of Accreditation Statements The DNS is used to publish two types of accreditation information: 1. Information that describes how accreditation records MAY be interpreted. 2. Accreditation records that describe the accreditation status of specific domains. The accreditation statements will in most cases be interpreted by an email filtering system that estimates the likelihood that the email message is wanted by combining information from a large number of sources. 3.1 Accreditation Authority Description Record The accreditation authority description record provides a link to an XML document that provides hints to help an email filtering system interpret the accreditation information. Such a filter can never be required to interpret any piece of data in a particular fashion since the data may be provided by an untrustworthy or even a malicious source. Knowing the type of information that an accreditation record expresses is useful when attempting to compare the information provided by one accreditation source with information from other sources. Accreditation sources that claim to provide the same type of information should show a high degree of correlation in the information they provide. Element Accredit The Accredit element is the toplevel element of an accreditation description and may contain one or more collections of accreditation data. Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 7] DNS Publication of Accreditation Data July 2004 The Accredit element may contain the following elements. Collection [One or more] A signature key that may be used to sign messages from the domain. The following schema defines the Accredit element: [TBS] Element Collection The Collection element specifies a collection of related accreditation data. The Collection element may contain the following attribute. Open If true the accreditation service is open and MAY be consulted to obtain information even if the sender does not list the service as an accreditor. The Collection element may contain the following elements. Protocol [Any number] A protocol that may be used to retrieve the data in the collection. Entry [Any number] A description of a data field entry The following schema defines the Collection element: [TBS] Element Protocol The Protocol element contains an identifier that specifies a protocol by which the data in the collection may be retrieved. The following value is defined: Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 8] DNS Publication of Accreditation Data July 2004 DNS-A The accreditation data is encoded in DNS A records. The following schema defines the Protocol element: [TBS] Element Entry The Entry element specifies the encoding of a data field within a collection. The Entry element may contain the following attributes Prefix An integer prefix value used to identify this entry when data is encoded using the DNS-A protocol. Position The bit field offset of the entry Length The number of bits used to encode the entry Scale {log2 | log10 | linear | none} The scale to be applied when comparing the corresponding record values. The following schema defines the Entry element: [TBS] 3.2 Sender Recipient A Record The data in the A record is interpreted using direction provided by the accreditation authority description record. The A record data field consists of four bytes. The existing convention established by real-time DNS blacklist schemes requires that the most significant byte of the address be 127 to indicate the host loop-back address and that the least significant bit of the address indicate the presence or absence of a party from a blacklist. Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 9] DNS Publication of Accreditation Data July 2004 Bits 24-31 Authority SHOULD set these bits to the value 127. Relying parties MUST ignore. Bits 16-23 Encode the prefix value used to distinguish between different data collections Bits 0-15 Encode the data values as specified by the bit field encoding descriptors. 3.3 Other Sender Recipient Records Additional information MAY be provided by means of other DNS records, for example TXT or NAPTR records. A Certificate Authority that has issued digital certificate(s) corresponding to an accreditation MAY publish links to the certificate in the accreditation record. 4. Filter Interpretation Guidelines An email filter MAY make any use it chooses of information provided. Accreditation information may come from an untrustworthy or even outright malicious source. The fact that an email sender is accredited by such a source MAY be considered a negative judgment on the reputation of the source. 4.1 Establishing Provider Reputation It is suggested that email filters SHOULD determine weightings to assign to accreditation notices from particular Accreditation Authorities by means of empirical measurement of their effectiveness rather than fixed a-priori values. If fixed weightings are assigned it SHOULD be possible to override these values. For example an email recipient receiving a large quantity of email might perform an analysis of the accuracy of various Accreditation Authorities on a statistically significant sample of that email. Recipients of smaller quantities of email might rely on third party assessments of the accuracy of Accreditation Authorities or on feedback from end-users identifying messages that have been wrongly categorized. Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 10] DNS Publication of Accreditation Data July 2004 4.2 Combining Accreditations When combining Accreditations from different Accreditation Providers filters MAY use the information provided in the Accreditation Authority Description record to determine whether the information provided is likely to have dependencies or not. For example an email sender that is accredited by two different Accreditation Authorities that verify identity information is not likely to be significantly less likely to be a spammer than an email sender that is only accredited by one Accreditation Authority. But an Email sender that is accredited by one Accreditation Authority that verifies identity information and another that monitors complaints from end users is less likely to be a spammer than a sender with only one of the accreditations. 5. Security Considerations 5.1 Unauthenticated or Wrongly Authenticated Sender A positive accreditation has no value if someone other than the accreditation subject can make use of it. It is therefore essential for the sender of an email to be accredited before a positive weight is given to an accreditation value. 5.2 Untrustworthy Accreditation Provider An Accreditation Authority may be untrustworthy for many reasons, they may perform their activities in a negligent fashion or with actual malice. For example a spammer might run an unrestricted accreditation service that accurately listed all his rivals as spammers but did not list the spammer who operated the service. Alternatively an Accreditation service may maliciously publish a negative reputation about a subject. For this reason email filters MUST evaluate the reputation of the Accreditation Authority as well as the data provided by that authority. The number of email senders that reference accreditation records published by an Accreditation Authority MAY provide an indication of the relative trustworthiness of that provider. 5.3 DNS Security Issues Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 11] DNS Publication of Accreditation Data July 2004 The DNS protocol does not provide cryptographic assurance of the integrity of the information published and is vulnerable to Denial of Service attacks. These weaknesses do not seriously affect the security of the accreditation mechanism when used for the purpose of spam reduction but may affect the security of the mechanism if it is applied to other purposes. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Meng Weng Wong, et. al., "Sender Policy Framework (SPF)", Internet draft, February 2004, http://spf.pobox.com/draft- mengwong-spf-00.txt 3 Microsoft Corp., "Caller ID for E-Mail Technical Specification", http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx 4 Paul Vixie, Proposal to IETF ASRG working group. http://www1.ietf.org/mail-archive/working- groups/asrg/current/msg04508.html 5 Microsoft Corp. "Coordinated Spam Reduction Initiative", February 2004, http://download.microsoft.com/download/7/6/b/76b1a9e6- e240-4678-bcc7-fa2d4c1142ea/csri.pdf Acknowledgments The author acknowledges the contributions made to this proposal by Jeff Burstein and Nico Popp of VeriSign, Meng Weng Wong of PoBox.com and Bob Atkinson of Microsoft. Author's Addresses Phillip Hallam-Baker VeriSign Inc. Email: pbaker@verisign.com Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 12]