Internet DRAFT - draft-hallambaker-accredit
draft-hallambaker-accredit
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=<domain>
The value <domain> specifies the location of the accreditation
service.
If the value of <domain> 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 <cdr> 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:
<ep xmlns='http://ms.net/1'>
<out>
<cdl>accredit.test</cdl>
</out>
</ep>
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]
