P. Hallam-Baker
Internet Draft VeriSign Inc.
Document: draft-hallambaker-consent-00.txt July 2004
Expires: October 2005
Proof of Consent Mechanism
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
We propose a mechanism Proof of Consent that allows an
email recipient to provide verifiable proof of æopt-inÆ
consent to receive email. Proof of Consent may be used
to automatically whitelist email from mailing lists and
email forwarded from another email server.
Proof of Consent is designed to require minimal state
maintenance by both the email sender and the recipient
and to be deployable with minimal impact on existing
email infrastructure.
1. Requirements
The Proof of Consent mechanism provides a verifiable and
revocable proof that a recipient consented to receive
email from a specified source. It is designed to address
several of the existing problems of maintaining mailing
lists and other consent based bulk mail such as
newsletters and solicited advertisements.
We note that other protocols such as Really Simple
Syndication (RSS) and Network News Transport Protocol
(NNTP) offer facilities that are similar to mailing lists
without the need for a proof of consent mechanism.
Despite the existence of these mechanisms email remains
the most commonly used means of obtaining data of this
type and it is appropriate to address these requirements
in the context of email mailing lists despite the
existence of alternative protocols that already meet
them.
1.1 Subscription Consent Problem
The SMTP protocol does not provide a means to allow a
mail server receiving a message alleged to have been sent
to a mailing list message to determine whether it was
solicited or not.
1.2 Reputation Attacks
An SMTP mail server may be falsely accused of having sent
messages to a non-subscriber.
As the situation currently stands there is no way to
determine the truth or falsehood of such allegations. A
party may even sign up for a newsletter with opposing
views so as to be able to complain about the messages
sent and hope to cause the mailing list to be put on a
blacklist.
Events of this type have occurred in connection with
mailing lists of every political persuasion. When
complaints are made about a blacklisting they are
typically met with further hearsay accusations that the
accused was ænotoriousÆ.
1.3 Unsubscribe Problem
Mailing list users often find it difficult to
unsubscribe. In many cases requests to be unsubscribed
are sent to the entire list.
The un-subscription problem can be a serious problem when
an intermediary such as a mailing list gateway is
involved.
1.4 Abandoned Subscription Problem
Users often fail to unsubscribe from mailing lists,
causing huge volumes of mail to accumulate unread in an
unused account or an unread mail folder. In some cases
the subscribed email account is also abandoned.
Often a mail user will subscribe to a mailing list on a
speculative basis and find that they do not read the list
often.
1.5 Abandoned List Problem
Mailing lists are often created and then abandoned after
a period of time after falling into disuse. This can
create serious problems if a spammer after discovers an
abandoned list without an administrator and starts to
send messages to the list.
1.6 Maintenance Problem
The management of a high volume mailing list requires a
considerable amount of effort, largely because of the
need to manage the problems of subscribers who are unable
to unsubscribe, have abandoned subscriptions etc. Another
increasing concern for mailing list administrators is
that their lists may be blocked by blacklists, often
through no fault of their own due to reputation attacks.
2. Deployment Constraints
The deployed email infrastructure is the result of more
than twenty years of development, much of which has taken
place in an ad-hoc fashion. As such it is vital that any
proposal to change that infrastructure be compatible with
the infrastructure as deployed and not merely as it is
described in theoretical specifications.
2.1 SMTP Deployment Limitations
Many SMTP servers are poorly configured and perform
arbitrary and in many cases capricious modifications to
messages as they are transmitted.
2.2 SMTP Client Limitations
Adding features to SMTP clients is a slow process. The
features offered by mail readers have not changed
significantly in the past five years, basic principles of
mail delivery have been unchanged for almost ten years.
As a result few end users are likely to upgrade their
mail client in order to be able to take advantage of a
protocol meeting the requirements described.
2.3 Separate Servers for Incoming and Outgoing Mail
Enterprises are increasingly using separate mail servers
for incoming and outgoing mail. Even if the end user
interacts with a single server it is likely that incoming
mail will be pre-processed by some form of mail proxy,
particularly if anti-spam filtering is being performed.
2.4 Network Protocol Access Limitations
Many ISPs limit or block completely use of certain
Internet protocols. These blocks may be imposed for a
variety of reasons that include preventing spam, service
differentiation and caprice.
2.5 Existing Features Insufficiently Observed
Many of the problems with mailing lists could be
addressed by simply deploying the existing proposals in
[RFC2369]. These provide a mechanism that allows mailing
lists to use URIs to specify how users can perform
functions unsubscribe from a list.
A header of particular interest in this specification is
the Mailing-List header that uniquely identifies a
mailing list.
3. The Proof of Consent Protocol
The chief deficiency in the email protocols with respect
to the requirements is that an incoming mail server has
no means of determining whether a recipient did
legitimately consent to opt-in.
Most mailing list applications support the use of a
challenge/response protocol to verify subscription
requests. The mailing list sends the subscriber a
challenge token consisting of a string of characters. To
confirm subscription to the list the subscriber returns
the token to the mailing list.
The Proof of Consent mechanism proposes the use of a
second token that is created by the subscriberÆs incoming
mail server and forwarded together with the challenge
token to the mailing list. The mailing list then includes
a copy of the token in every email message sent to
provide the proof that it was solicited.
This mechanism minimizes the need for state maintenance
at each stage in the mail transfer protocol, avoiding the
need for additional per user records to be stored at
either the incoming or outgoing servers.
3.1 Initialization
The incoming mail server establishes a shared secret k.
In the case that there are multiple incoming servers the
shared secret may be established manually or by means of
some form of key agreement protocol using public key
based credentials.
Once established, the shared secret is maintained for an
extended time period such as a year. Incoming mail
servers must keep a record of all shared secrets that
have ever been used and the validity intervals in which
they were used.
3.2 Confirmation Code
During the subscription process we establish a
confirmation code that is cryptographically bound to the
mailing list name, the recipient email address and the
date of subscription by means of the shared secret:
Code = MAC (mailing-list, recipient, date)
Where:
list
The string the mailing list will use in the
Mailing-List header
recipient
The email address of the recipient
date
The day on which the subscription took place.
Each message sent from the mailing list contains a
Confirmation-Code header as follows:
Confirmation-Code: <date> <confirmation>
The mailing list already needs to maintain a per-
subscriber record of mailing addresses. The additional
state required to support the confirmation code protocol
is negligible.
We require the subscription date to be stored explicitly
for two reasons, first it requires the mailing list
administrator to take notice of the age of subscriptions,
secondly it allows the incoming mail server to reject
mail with a stale confirmation code that is many years
old. This allows a mail server to reject mail sent to a
mailing list that a previous holder of an account name
subscribed to.
The incoming mail server can authenticate a confirmation
code (but not the attached message) by means of the
shared secret. Note that it is not necessary for the MAC
algorithm to be standardized, it is sufficient for the
sender and receiver to use the same one.
3.3 Subscription Process
The confirmation code is generated during the
subscription process and communicated to the mailing list
server.
We assume that any subscription process involves a
confirmation process by means of an email callback loop
challenge. The incoming mail server detects a mailing
list request for subscription confirmation and causes it
to be redirected so that the appropriate confirmation
code can be added.
The callback loop challenge contains a new header
constructed as follows:
Challenge-Code: <mailing-list> <recipient> <opaque>
Where
mailing-list
The string the mailing list will use in the
Mailing-List header
recipient
The email address of the recipient
opaque
An opaque code defined by the mailing list
confirmation server to be used for confirmation
purposes.
If the user responds to the confirmation request the
appropriate challenge code is generated and forwarded to
the indicated address along with the opaque code to
establish that the user did intend to subscribe.
3.4 Legacy Subscriptions
The confirmation code protocol must support gradual
introduction. It must be possible for a mailing list to
deploy the protocol without having to re-subscribe
existing users. It would be advantageous if this can be
achieved in such a way that allows a mailing list
administrator to be able to deploy the protocol
incrementally and still be able to establish that
unsolicited messages are never sent.
When a mailing list server sends a message to a legacy
subscriber the confirmation-code header is still present
but only the date field is filled, the confirmation field
is absent. This alerts the incoming server to the fact
that the message is purported to be a legacy
subscription.
If the incoming server supports the confirmation code
protocol it may query the user to determine whether the
subscription is actually authorized and if so provide the
relevant confirmation code to the mailing list server to
avoid the need for subsequent authorizations.
A similar procedure may be employed when the confirmation
code protocol is deployed on an existing incoming mail
server. In this case it is recommended that the service
provide some mechanism to allow the user to send
confirmation codes to a group of mailing lists at the
same time.
Mailing list administrators may defend themselves against
malicious allegations by having a copy of the mailing
list signed by a digital notary at the time the protocol
is deployed. The signature format may be chosen in such a
way that validity of each entry in the list may be
determined independently without revealing any
information about any other list member. Various schemes
suggest themselves including use of Merkle hash trees or
the XML Signature manifest object. It is recommended that
any mechanism chosen use a random mask value within each
entry to prevent attackers from finding out that a
specified party has subscribed to a list.
This information could be made available through some
form of protocol, however it is likely that requiring
existing users to re-subscribe will prove more
attractive.
3.5 Revocation of Confirmation Codes
The mechanism described only provides for the
authenticity of subscription requests to be established.
No assurance is provided for un-subscription requests,
nor is the protocol easily modified to achieve this
directly.
The confirmation code is cryptographically bound to the
mailing list identifier. An incoming mail server or spam
filtering application can filter incoming mail on the
basis of the mailing list identifier. Although this
requires the service to maintain state the overhead is
minimal and saves considerable resources in the long run.
A mailing list may choose not to observe requests to
unsubscribe but there is no incentive to do so if the
messages are unlikely to be read.
4. Security Considerations
4.1 Replay Attack
The consent to receive mechanism provides proof that the
recipient of an email message has consented to receive
messages from a specified source. It does not provide
definitive proof that a particular message originates
from the source specified.
An attacker that obtains a consent token for a particular
recipient/sender combination can generate an arbitrary
volume of messages containing the token.
This vulnerability is unlikely to represent a significant
risk in the context of spam mitigation. It is highly
unlikely that a spammer could obtain a sufficiently large
number of consent tokens to make bulk distribution of
spam through this mechanism feasible.
The vulnerability may be eliminated through use of the
consent token mechanism in combination with an
authentication mechanism.
References
[RFC2369] http://www.ietf.org/rfc/rfc2369.txt
[ListSpec] http://www.nisto.com/listspec/
Copyright Statement
Copyright (C) The Internet Society (year). 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 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."
Author's Addresses
Phillip Hallam-Baker
VeriSign Inc.
Email: pbaker@verisign.com