[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Asrg] Accreditation Mechanism Proposal
All,
A proposal for an accreditation mechanism is attached. This proposal
is based on the earlier RBL scheme proposed by Vixie, and designed to be
compatible with CallerID. I will submit as an ID later on today.
Basically the scheme returns an A record in response to a lookup. So
in order for example.com to announce that it is accredited by the class3
service of verisign the SPF or CallerID record would contain the tripple:
"accreditation" "class3.verisign.com""DNS-A"
I.e. this is an accreditation property, the accreditor service is at
class3.verisign.com, the protocol is a DNS A record lookup.
We can conflate the "accreditation" and "DNS-A" components, but that
is a bad idea, the A record convention is pretty limiting, there are only 24
bits worth of data that can be returned. It would be useful to be able to
extend to use of other protocol records such as NAPTR and SRV.
Some folk inside VeriSign suggested that we use the convention that
an unlisted domain just returns domain does not exist.
I believe that we should have some facility here for a description
of the accreditation service. This is because the receiver has to arrive at
an evaluation of the accreditation service before the information can
converge. The ability to use learning systems is very attractive here.
Telling the learning system basic information about the format of the data
is pretty useful, what is the basis that the info was collected on, is the
data bit field formatted or in some other form?
I provide the start of a description language here but on second
thoughts the best approach here would be to write the data structure in XML,
stick it up on a web site and put the URL in the DNS. The format is not a
big priority for me at the moment since it only really affects the
accreditation services and the filter writers. I don't think that either
community will be particularly large (10 to 20 at most). It is not something
we need to make a priority when we are using our limited standards track
bandwidth.
Phill
ASRG Working Group
Internet Draft P. Hallam-Baker
Document: draft-spf-accreditation-00.txt VeriSign Inc.
Expires: September 2004 March 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 - September 2004 [Page 1]
DNS Publication of Accreditation Data March 2004
Table of Contents
1. Introduction...................................................2
1.1 Accreditation Authorities..................................2
1.2 Accreditation Statements...................................4
1.3 Publication of Accreditation Statements....................4
1.4 Interpretation of Accreditation Statements.................5
2. DNS Publication of Accreditation Statements....................5
2.1 Accreditation Authority Description TXT Record.............7
2.2 Sender Recipient A Record..................................8
2.3 Sender Recipient TXT Record................................8
3. Filter Interpretation Guidelines...............................8
3.1 Establishing Provider Reputation...........................9
3.2 Combining Accreditations...................................9
4. Security Considerations........................................9
4.1 Unauthenticated or Wrongly Authenticated Sender............9
4.2 Untrustworthy Accreditation Provider......................10
4.3 DNS Security Issues.......................................10
References.......................................................10
Acknowledgments..................................................11
Author's Addresses...............................................11
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].
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].
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
Hallam-Baker Expires - September 2004 [Page 2]
DNS Publication of Accreditation Data March 2004
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.
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.
Hallam-Baker Expires - September 2004 [Page 3]
DNS Publication of Accreditation Data March 2004
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 accreditation mechanism 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
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
Hallam-Baker Expires - September 2004 [Page 4]
DNS Publication of Accreditation Data March 2004
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 used.
1.7 Accreditation Authority Description Data
The domain prefix specified for an accreditation service MAY
contain a record that describes the use of the particular
accreditation service with the key _accredit.
1.8 Interpretation of Accreditation Statements
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.
Hallam-Baker Expires - September 2004 [Page 5]
DNS Publication of Accreditation Data March 2004
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.test.
The sender recipient record 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
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.
Hallam-Baker Expires - September 2004 [Page 6]
DNS Publication of Accreditation Data March 2004
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 TXT Record
The accreditation authority description record provides such a filter
with hints that 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.
type:{ identity | undertaking | performance }
The type of accreditation provided as described in the
introduction.
open:<boolean>
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.
protocol: {dns-a | dns-txt | other }
The protocol by which the accreditation may be retrieved.
The keyword dns-a specifies that the accreditation record is
encoded as a DNS A record. The keyword dns-txt specifies
that the accreditation record is encoded as a DNS TXT
record.
length:<integer>
The number of bits in the record value that have
significance.
Hallam-Baker Expires - September 2004 [Page 7]
DNS Publication of Accreditation Data March 2004
scale: {log2 | log10 | linear | none}
The scale to be applied when comparing the corresponding
record values.
3.2 Sender Recipient A Record
The data in the A record is interpreted using direction provided by
the accreditation authority description TXT 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.
Bits 24-31
Authority SHOULD set these bits to the value 127. Relying
parties MUST ignore.
Bits 8-23
These bits are used to encode the scale value
Bits 4-7
These bits are reserved. Relying parties MUST ignore
Bits 0-3
If the subject is accredited these bits are set to the value
10. If the subject is not accredited these bits are set to the
value 15.
This convention is broadly compatible with existing conventions,
including those specified in the CSRI and SPF specifications.
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
Hallam-Baker Expires - September 2004 [Page 8]
DNS Publication of Accreditation Data March 2004
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.
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.
Hallam-Baker Expires - September 2004 [Page 9]
DNS Publication of Accreditation Data March 2004
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
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
Hallam-Baker Expires - September 2004 [Page 10]
DNS Publication of Accreditation Data March 2004
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-Baker Expires - September 2004 [Page 11]