mass D. Otis
Internet-Draft Trend Micro
Expires: March 10, 2006 September 6, 2005
MASS impacts upon reputation
draft-otis-mass-reputation-02
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 March 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document responds to findings in the MASS review by Russell
Housley et al, with additional considerations from the perspective of
reputation assessment. This also includes speculations on possible
solutions and implementations for the MASS proposal: DKIM.
Otis Expires March 10, 2006 [Page 1]
Internet-Draft MASS-Rep September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Resource Preservation . . . . . . . . . . . . . . . . . . . 3
3. Community Policies . . . . . . . . . . . . . . . . . . . . . 4
4. Filtering Erodes Integrity . . . . . . . . . . . . . . . . . 5
5. Mailbox-domain Authorization . . . . . . . . . . . . . . . . 6
6. The Hack for Mailbox-Domain Authorization . . . . . . . . . 8
7. Protecting Recipients without using Mailbox-domain
Authorization . . . . . . . . . . . . . . . . . . . . . . . 10
8. Detecting a Path Change . . . . . . . . . . . . . . . . . . 12
9. Binding Identifiers . . . . . . . . . . . . . . . . . . . . 13
10. The next steps in enforcement . . . . . . . . . . . . . . . 15
11. PKI certificates per user would burden larger domains . . . 16
12. Key size and performance . . . . . . . . . . . . . . . . . . 17
13. Border Validation . . . . . . . . . . . . . . . . . . . . . 18
14. Domain Assertions for Signatures . . . . . . . . . . . . . . 20
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . 20
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
18.1 References - Normative . . . . . . . . . . . . . . . . . 22
18.2 References - Informative . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . 25
Otis Expires March 10, 2006 [Page 2]
Internet-Draft MASS-Rep September 2005
1. Introduction
Laws governing email policy do not always prohibit unsolicited
commercial email (UCE). It is necessary that more stringent email
policies are used by sending domains as demanded by recipients.
Signatures, validated by keys published within DNS, allow recipients
a stronger means to ascertain those domains most directly accountable
for policies applied to the messages being offered. The reputation
of entities submitting messages often determines acceptance, although
the assessed identity is normally the IP address. Many domains use a
shared outbound IP address and this may result in collateral
refusals. Signed messages offer a stronger, and more specific
accountable domain than that of the IP address. However, the use of
domain signed messages is not a panacea. The current [DKIM]
specification creates challenges when attempting to squelch policy
breaches, see [ID-Housley-MASS]. Also, the overhead required to
implement signatures, as compared to the use of an IP address for
reputation assessment, requires additional defensive measures.
Terminology: Terminology conforms to [ID-email-arch].
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 [RFC2119].
2. Resource Preservation
The prevalence of undesirable email reaches levels where a decision
to refuse a session MUST be made prior to the message exchange to
conserve network and system resources. The decision to refuse a
session is typically based upon accrued reputations, or the access
type listed by providers for the remote IP address in question. A
similar level of protection is possible by basing reputations upon a
verified HELO/EHLO names. Verifying the HELO/EHLO name demands that
clients insure requisite DNS information is reliably returned, see
[ID-CSV]. Accepted practices currently forgive HELO/EHLO names that
do not verify, as allowed by [RFC2821]. To establish effective name-
based reputations to defend message signature verification
operations, HELO/EHLO name verification is REQUIRED. Verifiable
HELO/EHLO names or domain signatures offer an alternative to the use
of the IP address as a basis for accruing reputations. Name-based
reputations may avoid collateral refusals, however, verifications of
the HELO/EHLO name provide vital network and system resource
protection.
A signed message permits inclusion of a new identifier that can not
be falsified. The signing-domain can add an opaque-identifier
together with recommendations regarding the use of this identifier in
Otis Expires March 10, 2006 [Page 3]
Internet-Draft MASS-Rep September 2005
conjunction with mailbox-addresses. In addition to improving
protections available to recipients, this identifier can also be used
to abate abusive message replays. The lookup required to detect a
revocation of the opaque-identifier, can be mitigated by the HELO/
EHLO name being within the signing-domain, or by a valid hash of the
[RFC2821] RCPT TO parameter.
Resource protection mechanisms SHOULD be based upon a single DNS
lookup to verify the authorization and authentication of the sending
SMTP client. When, by convention, the HELO/EHLO name is normally
within the signing-domain, then a few other efficiencies are made
possible. It becomes possible to skip reputation checks for the
signing-domain after a reputation check of a HELO/EHLO name that is
within the signing-domain. As mentioned, when the HELO/EHLO name is
within the signing-domain, checking the status of a specific opaque-
identifier should not be needed. Had the account been revoked, it
SHOULD be impossible for these messages to be signed with a revoked
opaque-identifier.
Systems suffering a security breach have become a significant vehicle
for sending abusive email. Millions of compromised systems may act
as SMTP clients or utilize automated access to the provider's SMTP
servers. Any mechanism enforcing email policy SHOULD verify the
source domain or use the remote IP address as a basis for reputation
accrual. As a result of domain verification, those accountable for
maintaining security will have been determined when abuse is
discovered. Authentication ensures the validity of these identifiers
used as a basis for network protection. Assumptions regarding
sources of abusive email or a presumption of security may injure
innocent parties and damage the integrity of email delivery.
With tens of millions of good and bad evolving email domains, it is
less effective to abate abuse or maintain security where each
recipient contemporaneously establishes acceptance criteria. White-
listing large domains, demonstrating good governance controlling
abuse, will categorize a major portion of the messages being
assessed. While this reduces number of messages needing evaluation,
the categorization of remaining sources still represents a sizable
expense. Often a community of administrators pool efforts and create
shared lists that offer histories for an extensive number of email
sources.
3. Community Policies
The pooling of efforts is often accomplished through reputation
services as a means to establish policy within a community. Those
with even a brief history of not adhering to these policies are
thereby excluded community. Real-time black-hole lists have become a
Otis Expires March 10, 2006 [Page 4]
Internet-Draft MASS-Rep September 2005
commonly used mechanism to publish IP addresses related reputations,
where having no record returned indicates a good reputation. As an
example, a community wishing to enforce an Opt-In requirement for
bulk email, often employs an email reputation service to establish
such community-wide policy.
Reputation service subscription fees, if any, are typically paid by
the recipient. With such a service, those sending abusive levels of
unrequested email to anyone within the community may find subsequent
sessions refused with an error response. This response often
indicates which reputation service reported their server as not
having a good reputation with respect to specific polices. The
extent of email abuse has made reputation services an integral
component of network resource protection.
Some bulk email distributors also utilize a vouching or accreditation
service which attests their compliance to specific policies. To
benefit from the accreditation, the recipient must rely upon the
service, but fees for this type of service are usually paid by the
sender. Mechanisms for accreditation services are often similar to
real-time black-hole lists, except the record may also assert
favorable ratings.
Sender based fee structures for accreditation may provide greater
latitude for senders, and therefore tend to dissuade some domain
administrators from utilizing these services. Some providers may
utilize accreditation services together with their own white-listing
of bulk email distributors, as an adjunct to real-time black-hole
listings. White-listing by IP address is difficult to maintain.
Accreditation services assist with this white-listing effort for bulk
distributors where their volumes often mislead filtering algorithms
that categorize the distributors as abusers.
4. Filtering Erodes Integrity
Filter programs often place messages into several categories.
Placement of messages into suspense pending review, often hides the
filter's actions, and inhibits challenges by senders. Often, when
filtering provides multiple categories, a portion of these categories
are marked suspicious and left to the recipient to make a final
determination. The lack of feedback prevents assurance of email
delivery. There MUST be an ability to challenge a categorization to
ensure the integrity of email delivery. A filter program's "Junk"
folder contains email that has not been properly excluded by policy
enforcement, but is without a strong basis for rejection.
Even when a filtered message is rejected which provides feedback, it
may be due to a phrase contained within the message. A doctor's
Otis Expires March 10, 2006 [Page 5]
Internet-Draft MASS-Rep September 2005
reply to a patient may be steadfastly rejected regardless of which
provider is used. Unfortunately, many of these filter programs have
evolved to also silently discard messages, once some level of
heuristics has been achieved. This mode removes all traces of the
message for both the sender and the recipient. As a result of a
breakdown in policy enforcement and the resulting reliance upon
filters, which silently discard as well as place messages into the
often ignored "Junk" folder, the integrity of email delivery has been
reduced.
5. Mailbox-domain Authorization
As a basic principle, abuse prevention REQUIRES source verification
and accrual of reputation. For effective abuse prevention, sources
SHOULD resolve to the sending domain to establish an appropriate
hierarchy of accountability. However, adding recipient overhead for
discovering mailbox-domain authorizations increases the risk that the
recipient's resources will be exhausted. Furthermore, after the
recipient expends these efforts to determine a mailbox-domain's
authorization, this authorization could be inappropriately considered
equivalent to having verified the source domain for purposes of
accruing reputations.
There have been several schemes proposing accrual of mailbox-domain
reputations, often using recipient feedback techniques. This accrual
erroneously presumes that the mailbox-domain has been authenticated
rather than just authorized. When recipients consider path or
signing-domain based authorizations being equivalent to verifying the
source domain, this creates an unfair basis for accruing reputations.
The mailbox-domain owner often has no administrative oversight to
assure the protection of their mailbox-domain's reputation. Instead
of authorization records preventing harm, these authorization records
may actually cause an otherwise unevaluated mailbox-domain to obtain
a bad reputation, when a mailbox-domain is still falsified by abusive
messages.
Assuming the recipient checks for mailbox-domain authorizations, the
anticipated benefit of preventing misuse then depends upon the
mailbox-domain owner accepting additional conditions. The mailbox-
domain owner MUST fully depend upon a provider ensuring the
exclusivity of the outbound mailbox-domain. Also, the mailbox-domain
owner MUST accept the loss of emails in some cases. This loss occurs
when the authorization mechanisms are limited to commonly visible
mailbox-domains that are in conflict with existing email conventions.
Granting authorization exceptions to accommodate differing existing
conventions offers opportunities for exploits. Not granting
exceptions increases the support needed for non-conforming mechanisms
that result in email loss.
Otis Expires March 10, 2006 [Page 6]
Internet-Draft MASS-Rep September 2005
Authorization schemes devise mailbox-domain/signing-domain or
mailbox-domain/path relationships. Establishing these relationships
entails significant administrative effort as well as protocol
overhead. Exceptions granted may potentially mislead recipients, by
offering false assurances when the mailbox-domain authorization
mechanism indicates success. Proponents of mailbox-domain
authorization mechanisms ignore the uncertainty of the mailbox-
domain's visibility, selection, and origin. Recipients will still
confront abuse from authorized mailbox-domains. Reputations based
upon mailbox-domains may create unwarranted email delivery failures.
The inappropriate application of reputation occurs when recipients
attempt to hold potentially falsified authorized mailbox-domains
accountable, as a means to abate the abuse.
Currently abusers control millions of compromised systems, and can
take advantage of weak mailbox-domain authorizations. Abusers may
exploit published records that register permitted mailbox-domain
paths or signing-domains, to usurp previously good reputations. When
abuse occurs that still falsifies the mailbox-domain, the mailbox-
domain's tainted reputation may subsequently cause this domain's
emails to be blocked. What is worse, redemption of a mailbox-
domain's reputation may not be practical due to the typical mailbox-
domain multi-level authorization scheme that follows a filtering
paradigm. The mailbox-domain may not receive notification their
emails are being placed into "Junk" folders.
There are many weaknesses associated with path or signing-domain
based authorizations where the mailbox-domain can still be falsified.
Abusers may take advantage of a mailbox-domain's desire to ensure
emails are delivered by allowing exceptions. Abusers may also take
advantage of an email provider's failure to check mailbox-domain
authorizations, or failure to license mailbox-domain selection
algorithms. Nevertheless, with these flawed schemes, the mailbox-
domain within the selected header is held accountable for having sent
the message, when this accountability is only supported by
authorization records.
Some call this unfair assumption that holds the mailbox-domain
accountable, "Sender Authentication." Calling mailbox-domain
authorization "Sender Authentication" would be similar to making a
declaration that the postal service is authorized to deliver letters
for John Doe, where recipients then claim any letter received from
the postal service and bearing John Doe's name is authentically or
genuinely from John Doe. Of course, that would be a false assumption,
and path or signing-domain based authorizations are no different. It
is normal for mailbox-domains to employ common service providers. It
is also normal for service providers not to adopt specific checks
requiring extensive support. Mailbox-domain authorizations do not
Otis Expires March 10, 2006 [Page 7]
Internet-Draft MASS-Rep September 2005
provide a safe and practical solution for mailbox-domain
falsification.
6. The Hack for Mailbox-Domain Authorization
How will abusers take advantage of normal desires and the false
assumptions surrounding mailbox-domain authorization? While strictly
limiting authorization to just an email provider's servers could
reduce risks of a mailbox-domain being falsified, this could also
cause some messages to be lost as a result. The loss could occur
when recipient's providers select accountable mailbox-domains using
an incompatible algorithm. Recipients could also be forwarding
messages which may result in email losses. For example, with
messages first sent to an alma mater's domain, forwarding may make
messages appear to be unauthorized. Messages may also be lost when
sent through some list-servers, or through servers running older
versions of email applications.
Why quibble over who is responsible for implementing changes that
often takes many years? For the loss of messages due to an
incompatible authorization scheme, the remedy invariably suggested
would be to leave mailbox-domain authorization open-ended. Open-
ended authorization simply declares a lower level of authorization
rather than authorization failure. The multiple levels of
authorization is intended to alert recipients to increase scrutiny
given messages with lower levels. However, this lower level of
authorization can not ensure the mailbox-domain's reputation remains
protected. For example, abusers can take advantage of automatic
image fetching to compile valuable lists of active email accounts by
using encoded image links. These abusers don't care which folder or
level of authorization they obtain. They don't care that recipients
fail to respond, and they would be thrilled to see recipients make
the effort to unsubscribe.
The mailbox-domain owner's next concern is whether the recipient of a
message clicks the "spam" button when messages have falsified their
mailbox-domain. Conventions remain uncertain for selecting the
header being checked for authorization. Email providers rely on
open-source applications and are understandably reluctant to enter
into licensing terms that are hostile to the open-source methods of
software distribution. It is also understandable some providers will
only consider using non-proprietary algorithms for basing their
assumptions of who originated the message. These providers can not
inspect some headers without violating claims of intellectual
property, when there are also proprietary header selection
algorithms. Each selection approach creates compatibility issues
requiring differing mitigations.
Otis Expires March 10, 2006 [Page 8]
Internet-Draft MASS-Rep September 2005
Some providers will utilize a proprietary algorithm and enforce their
view by incorporating reputation extensions into MUA plug-ins that
take an already unfair basis for reputation to a new level of being
unfair. With either path or signing-domain authorization records
being very public, a mailbox-domain's reputation will be exposed to
any possible weakness. Publishing open-ended authorization records
may even act as an invitation for this abuse. Furthermore, a
provider that does not ensure message headers are not in conflict
with other customers across all possible interpretations, may risk
their customer's mailbox-domain's reputation, especially when this
provider's limitation becomes known.
With phishing techniques becoming seemingly epidemic, mailbox-domain
authorization is often touted as a remedy. With respect to phishing,
these authorization schemes may bypass the From header as the basis
for acceptance, even though this is the header typically assumed as
verified by recipients. Some MUAs have made this problem worse by
displaying user friendly names, known as the "pretty" names, rather
than the actual mailbox address. Phishing ploys often use disposable
domain names with obfuscated links, which could also provide a
variety of mailbox-domain authorizations as a means to obtain false
assurances.
Mailbox-domain authorization records can covertly authorize the
entire Internet to enable a compromised system anywhere in the world.
Mailbox-domain authorization, as a phishing deterrent, presumes wide
adoption of an algorithm by mail clients and providers. However,
assurances, offered by mailbox-domain authorization "aware"
applications, are dangerous, due to the possible use of hidden
headers, and reliance upon uncertain interim authorization checks.
This may actually place consumers in greater peril, when trusting
false assurances.
Mailbox-domain authorization requires that mailbox-domain owners
trust their email providers, although many providers do not
authenticate their own customers, and do not care what mailbox-domain
is used. Such providers will be exposing to substantial risks the
mailbox-domain owners who publish mailbox-domain authorization
records. Mailbox-domain authorization does not identify these
providers either, so there is no accountability that directly assures
a provider's diligence.
Mailbox-domain authorization itself may weaken the integrity of the
DNS. One draft risking the integrity of DNS only offers the advice
that providers use "properly paranoid DNS resolvers." Path based
authorization records catalog all outbound MTAs of a domain and may
demand a minimum of more than one hundred DNS lookups, while also
ignoring UDP exponential back-off. Signed-domain authorization
Otis Expires March 10, 2006 [Page 9]
Internet-Draft MASS-Rep September 2005
records require walking up the DNS label tree from five levels below
the root. This occurs for mailbox-domains that have not made an
indication that a mailbox-domain authorization scheme is supported.
This will increase DNS traffic and likely obligate root name servers
to issue negative authorization records to mitigate the authorization
query overhead. Mailbox-domain authorization records can not offer
network resource protection, but actually put these resources at
risk.
Publishing mailbox-domain authorization depends upon providers
inspecting all possible interpretations of the message headers and
envelope parameters. To do this, providers may either limit their
customer's choice of mailbox-domains, or isolate their customers
outbound servers or IP address. The mailbox-domain owner suffers the
harm when the provider is negligent at controlling access and
establishing the needed constraints, since the provider remains
anonymous. Furthermore, the mailbox-domain owner will be left in the
dark as to the cause of their dilemma.
7. Protecting Recipients without using Mailbox-domain Authorization
The opaque-identifier is a mechanism being suggested by this
document. The term 'opaque' means that only the domain creating the
identifier understands the relationships described. There could be
two modes used for creating the content of the opaque-identifier.
One mode would be persistent with the account used to access the
signing-domain, and the other could be sequential for cases where an
account is not involved. A prefix could be added to the sequential
opaque-identifier to prevent collisions with the identifiers used for
accounts.
A sequential opaque-identifier may be appropriate for distributing
bulk mailings. To identify the abusers that may attempt to stage
replay attacks, having a unique identifier sent to each recipient
could be helpful. These replay attacks could be done using the
unchanged content of the message, but to recipients that would
consider the information to be unsolicited. The reason for such a
replay attack may be to damage the reputation of the signing-domain.
If an identifier were added to an unsigned message, this would invite
forgery and therefore offer little value. A standardized opaque-
identifier, included within the validated content of a signed
message, would offer significant value. It would be an opaque-
identifier added to the signature header that is valid as a domain
name label. A persistent opaque-identifier would be most useful when
derived from the access server that authenticates the account being
used.
Otis Expires March 10, 2006 [Page 10]
Internet-Draft MASS-Rep September 2005
The opaque-identifier would greatly aid the correlation of abuse and
prove most useful for locating compromised systems. This approach
could be effective against systems compromised by Trojan programs,
stolen passwords, and cracked wireless access points, among many
other nefarious methods. Abuse reports that catalog signed messages
and that are correlated with the opaque-identifier, would provide
incontrovertible evidence of where the source of a problem exists.
The publishing of the revocation record for the opaque-identifier
would also provide feedback that actions were taken to rectify a
policy breach.
In odd cases, where the HELO/EHLO name is not contained within the
signing-domain and where the RCPT TO hash is not valid, a single
lookup of the opaque-identifier returning no record would be an
indication that this particular opaque-identifier is still authorized
by the signing-domain. This mechanism would be most valuable in
those cases where the message may have been forwarded, such as at the
typical alma mater, or where a mailing list opts to also forward
signed messages unaltered.
If there is a problem, the signature would offer the name of the most
capable domain to remedy abuse. People can still safely use their
forwarding email accounts given to them by their school or society.
Mailing lists would be given a strong identifier upon which to grant
the replication of messages. The best part, complaints would also
likely be directed to those most able to curtail future episodes of
bad behavior, i.e. the provider of the abusive account!
The construction of this revocation record mechanism could take the
form of a single A record lookup. The opaque-identifier would be
composed of 1 to 63 characters and select a record in this fashion:
Within the signature header, a parameter u=<opaque-identifier> would
indicate the use of a opaque-identifier.
<opaque-identifier> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= %x41-5A / %x61-7A
<digit> ::= %x30-39
Otis Expires March 10, 2006 [Page 11]
Internet-Draft MASS-Rep September 2005
<opaque-identifier>._rl.<signing-domain> IN A 127.0.0.2
When the signing-domain has not revoked authorization for this
identifier, no record would be returned and the remote DNS cache
would retain the absence of this record for a brief period of time,
see [RFC2308]. For the majority of cases, where messages are
obtained directly from the signing-domain, an exception granted by
the HELO/EHLO being within the signing-domain allows this revocation
check to be skipped. A revocation check would be made for the odd
cases where the HELO/EHLO is within a different domain and the RCPT
TO hash is not valid. This check would be performing nearly an
identical lookup now ubiquitously done to investigate the status of
the SMTP client's IP address against a real-time black-hole list.
Those addresses or identifiers that warrant refusal are granted a
long lived address record to ensure their immediate refusal and limit
DNS traffic resulting from abusive sources. Otherwise, not offering
a record allows for the prompt cessation of an opaque-identifier's
authorization when the situation regarding a particular identifier
changes. The Time-To-Live for negative DNS caching may be determined
by the recipient, or represent the lesser of the SOA TTL or the SOA
MINIMUM field, depending upon the recipient's implementation.
8. Detecting a Path Change
There are at least two techniques that can be used to detect when the
message's path has been altered. Verifying either check can mitigate
a need to do a revocation check on a opaque-identifier. One check
would be verifying the hash for the RCPT TO parameter is valid. The
other would be verifying the HELO/EHLO name confirming that it is
within the signing-domain.
The purpose of the RCPT TO hash would be to provide an indication of
when to check for the opaque-identifier revocation, as an alternative
to the HELO/EHLO being within the signing-domain. There should be
practical methods used on the RCPT TO line which obfuscates the
hashed information. Perhaps, randomly modifying the case of letters
within the mailbox-domain could act as a type of salt. The goal is
to mitigate extra DNS lookups, albeit small in this case. The RCPT
TO hash option would also instill a practice that provides better
tracking abilities when problems occur, without depending upon other
steps being taken.
The RCPT TO could use a white-space sensitive canonicalization that
combines the RCPT TO parameters into a single SHA-1 hash. This hash
would be added to the signature using base64 encoding as a "r="
parameter, for example.
List servers that pass messages unaltered, or recipients that employ
Otis Expires March 10, 2006 [Page 12]
Internet-Draft MASS-Rep September 2005
forwarding accounts could be fairly common scenarios where a
revocation check would be required. The reaction deterring the
replay attack must be rapid, but does not require all abusive
messages be stopped. This rapid response will expose participating
SMTP clients and reduce the profits of the abusive behavior. The
loss of the profits and the exposure will act as a deterrent.
9. Binding Identifiers
Binding identifiers allows a recipient to recognize a prior
correspondent without the use of complex and problematic mailbox-
domain authorizations. Mailbox-domain authorization issues may
create support issues that could significantly thwart [DKIM]
deployment. The MUA is able to associate visual items from prior
correspondents and obtain a higher granularity and history of signed
message sources without using any DNS lookups. The identification of
the message source is contained completely within the message itself.
When assuming legacy MUAs, scant protections are possible by the MTA
even using many DNS lookups. Due to limitations of ensuring
visibility of checked domains, the MTA approach provides an
alarmingly low level of mailbox-address protections. There is also a
potential for an undesired exposure of mailbox-addresses in the 'i='
parameter. Mailbox-domain authorizations depend upon the signing-
domain verifying the validity of the local-part of the mailbox-
address for the recipient to detect intra-domain spoofing.
A suggested approach could be used to detect when a previous
correspondent appears to be from a different origin. The approach
would rely upon the collected relationships discovered within signed
messages. The signed message may even advise what information should
be compared against the mailbox-address and perhaps even the pretty-
name. While in most cases the collected relationships (bindings)
would be made at the behest of the recipient and require their
approval, some relationships could be established automatically.
When the mailbox/signing domains are the same, and when the message
advises that only the mailbox/signing domains are essential to
identify the originator of a message, then it should be safe to
capture this relationship automatically. With the relationship
information captured (cached), the MTA or MUA would be able to detect
when a message violated these expected relationships.
To recognize the originator of a message when there are no assurances
being made regarding the mailbox-address, an opaque-identifier that
tracks accounts would be added by the signing-domain. This opaque-
identifier would become a part of the captured relationship once
approved by the recipient. A provision would be added to indicate
Otis Expires March 10, 2006 [Page 13]
Internet-Draft MASS-Rep September 2005
when a key had been delegated. The message signed with a delegated
key should not be trusted to make recommendations with respect to the
scope of a binding. This delegated key should also require the
opaque-identifier to equal the key-selector.
In the case of a particular domain that recommends only the signing/
mailbox domains be bound, after the initial contact by anyone within
that domain, comparing against the captured signing/mailbox domains
could indicate when the source of a message appears suspicious. If a
subsequent message appeared suspicious coming from a list server,
then the recipient could merge the list server domain within the
associated relationship. This approach would make it more
advantageous for list servers not to damage initial signatures.
Even for somebody@example.com, where example.com allows any mailbox-
address in the From header, but signs the out-going mail, the added
opaque-identifier would still permit detection of miscreants
attempting to pretend to be somebody@example.com. This approach
would not require the administration of a centralized database of
mailbox-domain authorizations.
There would be three modes expressed by the scope-width parameter
included within the signature header. A value of "w=n" would
indicate a narrow binding recommendation, and a value of "w=b" would
indicate a broad binding recommendation. A Narrow binding would
include mailbox-address/signing-domain/opaque-identifier, whereas the
Broad binding would include just the mailbox-domain/signing-domain.
No "w=" parameter would indicate that no bindings are recommended.
The suggested binding are recommendations for the type of pseudo-
certificate created to uniquely identify a correspondent for future
reference. One could argue that 'ssh' is one of the most widely used
cryptographic protocols, which often relies upon "opportunistic
cryptography" by saving self-signed certificates. This document is
suggesting this 'ssh' model could also work for [DKIM]. In the case
where the "w=b" and the mailbox-domain and signing-domain match, the
MUA, perhaps even the MTA, could cache the pseudo-certificates for
the correspondents.
When the "w=b" and the mailbox-domain and signing-domain match, then
after the initial correspondence with anyone within that domain, all
subsequent correspondences from anyone within that domain could share
the same pseudo-certificate. There should be an exception made when
a signing key has been delegated. The local-part and the binding
recommendations are less trusted in a delegated key. There should be
a parameter added to the delegated key where "d=n" parameter
indicates that the key has been delegated and the recommending
binding for delegated keys is narrow. In the case of a delegated
Otis Expires March 10, 2006 [Page 14]
Internet-Draft MASS-Rep September 2005
key, the opaque-identifier and the key selector MUST match.
10. The next steps in enforcement
Reduce reliance upon filtering that either discards or "junks"
messages. A growing loss of integrity in email delivery is eroding
email's value as a method for conducting transactions. This loss of
integrity is largely caused by filtering programs that process
messages based upon weak identifiers. A filter program's use of
heuristics with weak identifiers demands growing resources and may
cost senders the loss of their messages, even to the point where
their mailbox-domain becomes unusable, with no clear recourse for
correcting errant behaviors.
Remove advantages gained by spoofing the bounce-addresses by not
returning the original content of the bounced message within the
Delivery Status Notification (DSN). This should curtail the
exploitation of an MTA, that performs checks after accepting the
message with a spoofed bounce-address intended to be bounced. Reduce
the exposure to the DSN from messages with spoofed bounce-addresses
by implementing a time constrained cryptographic signature within the
local-part of the bounce-address for all messages sent, as described
in [ID-BATV].
Improve the integrity of email by using reputations based only upon
authenticated identities, where messages are either fully accepted or
refused. In email, there are only three identities that can be
authenticated: the IP address of the sending MTA, a somewhat stronger
HELO/EHLO, and a much stronger message signature. Authentication of
identities provides a means to fairly assess the sources for possible
abuse. The IP address and HELO/EHLO domain represent the
administrator for the last step in the message's delivery. A message
signature represents the domain administrator granting initial
access.
Protect the signature validation process by utilizing an
authenticated HELO/EHLO name to establish a reputation for the
session prior to an exchange of messages and prior to the validation
of signatures, see [ID-CSV]. The authentication and authorization of
the HELO/EHLO name can be validated within a single DNS lookup. The
DNS infrastructure that provides the signature keys also requires
better protections. Do not expect the DNS server to handle active
scripts that demand extensive lookups. Ultimately, the deployment of
[RFC3008] for DNSSEC is required.
Limit exposure to the replay of signed messages. Although a message
signature provides the strongest authentication and offers the
recipient the best protections from spoofing or phishing, it could be
Otis Expires March 10, 2006 [Page 15]
Internet-Draft MASS-Rep September 2005
abusively repeated beyond the signing domain's control. As a
defensive measure, when needed, a message signature should also
permit inclusion of an opaque-identifier. The opaque-identifier
would both ease correlation of abuse, and enable a means to squelch
"replay attacks." For example, when the key or signature remains
valid for one week, publishing a revocation record within minutes of
an abuse report would reduce replay exposure by a factor of 2000 to
1, and would clearly unveil replay sources to all recipients. While
message signatures offer little network protection, they indicate the
administrator most able to prevent future breaches of policy.
Message signatures also truly afford protections from the initial
sources being spoofed.
Assert email policy for the domain, see [ID-CSVCSA]. Currently this
DNS record allows a domain to assert that all of their SMTP clients
will be authorized and authenticated using [ID-CSV]. A signed
message allows safe assessment of the message source by making no
presumptions of intervening security. At an administrative border,
policy assertions, as well as the domains validated, may need to be
communicated to another MTA within the administrative domain, where
signature validation may occur. This document recommends a possible
structure for transferring this information.
11. PKI certificates per user would burden larger domains
The relative simplicity of the DKIM proposal represents an essential
element needed to sustain the performance demanded by the email
infrastructure. While policy enforcement necessitates cancellation
of access rights, using signatures also necessitates a need to revoke
user authorization implied by a valid signature. This is not
equivalent to a certificate revocation as defined for PKI in
[RFC3280]. A proposed method in this document achieves the
revocation mechanism, and only requires a simple exchange for
infrequent cases. In fact, certificates would be unsuitable for
fulfilling this need, as certificates per-user would represent an
undue burden.
For large providers, two certificates per user would be needed to
accommodate the mail transit time during a certificate change-over.
A domain with 20 million users would then require close to 7 GB of
data published on-line. Even when subsequent certificates are
phased-out in stages, any extended period for such staging would
increase the size of certificate revocation lists (CRL) which, to be
effective against abuse, would require frequent polling. Recipients
would then need to cache this voluminous information for all users
exchanging messages. As an alternative, by adding a persistent
identifier within the message, the amount of information exchanged
would represent 6 orders of magnitude reduction, while still
Otis Expires March 10, 2006 [Page 16]
Internet-Draft MASS-Rep September 2005
providing the same capabilities.
For the smaller providers, not incurring the added expense of
acquiring certificates helps reduce barriers to the deployment of
message signatures. A certificate authority typically ensures the
identity of the certificate holder, but is less concerned about
adherence to various email policies. There would still be a need to
verify the reputation of this identity against desired policies, as a
basis for accepting their messages. While using DNS to distribute
keys reduces what could be a substantial expense, this relatively
simple mechanism is not without risk.
12. Key size and performance
RSA keys are used by the proposal and, for this review, are assumed
to follow the outline in [RFC3447]. The processing to verify a
signature is roughly dependent upon the square of the key size. The
overhead associated with certificate or key handling is ameliorated
through retention within a cache for extended periods. In the summer
of 1995, RSA laboratories recommended a minimum key size of 768 bits
for user data, 1024 bit keys for enterprise keys, and 2048 bits for
root keys. Since that time, with Moore's law providing a doubling of
performance every 2.5 years, today's system's performance is
approximately 16 times faster. At an RSA challenge in August 1999, a
512-bit value was factored using 35.7 CPU-years. Other concerns
regarding the time to factor the key involve the advancement of
programmable or custom logic. These hardware advances further
increases the performance of factoring by thousands of times more,
especially for smaller keys where the needed memory size remains
practical.
Factoring memory requirements: [TWINKLE]
+----------+-------------+--------+-------+--------+
| Key Size | Time | Factor | Sieve | Matrix |
+----------+-------------+--------+-------+--------+
| 512 | 1.7 x 10^19 | 3MB | 128MB | 2GB |
| 768 | 1.1 x 10^23 | 240MB | 10GB | 160GB |
| 1024 | 1.3 x 10^26 | 7.5GB | 256GB | 10TB |
+----------+-------------+--------+-------+--------+
There are speculative estimates that with as little as $5,000 worth
of specialized hardware, a 768-bit key could be determined within 95
days, see [TWIRL]. Extrapolating from this figure, it may take
$200,000 to do this within 3 days. With the growing plunder achieved
by criminal activity that sends email to entice victims, this expense
may not be an adequate deterrent. Today's recommended minimum key
size of 1024-bits seems well justified. It will change to 2048-bits
Otis Expires March 10, 2006 [Page 17]
Internet-Draft MASS-Rep September 2005
by the year 2015, based on a tentative schedule provided by the NIST,
see [NIST-Keys]. [RFC3766] provides details relevant to assessing
key strength.
A very rough estimate of processing overhead for signatures assumes
that memory caching and higher processor performance provide about an
8 times improvement over memory bus rates. The following formula was
used to estimate performance:
(80,000 + 32 (key-bit-size^2) + 448(message-byte-size)) / bytes/
second memory-speed
Note: Once actual results are evaluated, constants within this
formula will need adjustment and should also vary between
different architectures.
At 768-bit keys and a CPU using 2100 MB/second memory, the overhead
for an 8 KB message estimates to be around 10.7 milliseconds. The
same parameters with a 1024-bit key would result in 17.8
milliseconds. This suggests that when changing from 768-bit to 1024-
bit keys, the resulting overhead should increase by a factor of about
1.6. Such a CPU using 2100 MB/second memory dedicated to performing
this operation, could then handle daily about 4.8 million messages
that average 8 KB in size.
+--------------+----------------+-------------+
| Message Size | Signature Time | Message/min |
+--------------+----------------+-------------+
| 1,000 | 16 ms | 3,700 |
| 5000 | 17 ms | 3,500 |
| 10,000 | 18 ms | 3,300 |
| 50,000 | 27 ms | 2,300 |
| 100,000 | 37 ms | 1,600 |
+--------------+----------------+-------------+
This table is for a CPU using 2100 MB/second memory validating 1024-
bit keys. This shows that beyond 100,000 byte messages, the much
faster hash function becomes predominately the limiting factor.
13. Border Validation
To provide the conveyance of information obtained at the receiving
administrative border, a new header is introduced. This header
documents the methods and results of message validations performed.
It is added at the top of the message solely by the Internet facing
border MTA. Any previous Border-Validation header introduced at the
Internet facing MTA should be stripped and may be viewed as an
attempt to forge this information and cause the message to be
Otis Expires March 10, 2006 [Page 18]
Internet-Draft MASS-Rep September 2005
rejected. This header has the following format:
header := "Border-Validation" ":" domain"["address-literal"]"
1*LWSP *(";" method "=" result)
domain := Domain as defined in [RFC2821]
address-literal := Address literal as defined in [RFC2821]
method := "CSV" | "DKIM" | "RDNS" | "A-RR"
result := authen "/" author "/" assert "/" time "/" hash
authen := "VALID" | "INVALID" | "UNKNOWN" | "ERROR"
author := "VERIFIED" | "MISSING" | "UNKNOWN" | "ERROR"
assert := hexadecimal presentation of the CSV-CSA port field.
time := time value defined by recipient
hash := defined by recipient to cover domain, address-literal,
method, and result.
LWSP := 0x20 / 0x09
"CSV" refers to the procedures defined in [ID-CSV]. "DKIM" refers to
the procedures defined in [DKIM]. "RDNS" refers to the validation of
the HELO by using a reverse DNS lookup of the remote client IP
address and verifying the HELO name, which will provide "UNKNOWN"
authorization. "A-RR" refers to using a lookup of an address record
for the HELO name, which will also provide "UNKNOWN" authorization.
Authen is for authentication and author is for authorization. A
"VALID" authentication indicates the domain has been confirmed by the
method indicated. "INVALID" indicates the method attempting
authentication has failed. A message that fails authentication
should be refused. An authentication returning "UNKNOWN" indicates
the client does not conform to a standard which assures
authentication. Authentication returning "ERROR" indicates a system
related failure has prevented a determination.
A "VERIFIED" authorization indicates the client supports [ID-CSV]. A
"MISSING" authorization indicates the client supports [ID-CSV] or
[DKIM] but has determined the client or message is not authorized.
Normally this should cause the message to be refused. "UNKNOWN"
authorization indicates the client does not support [ID-CSV].
Authorization returning "ERROR" indicates a system related failure
Otis Expires March 10, 2006 [Page 19]
Internet-Draft MASS-Rep September 2005
has prevented a determination.
14. Domain Assertions for Signatures
[ID-CSV] provides a means to make domain-wide assertions. Currently,
only the use of CSV itself is defined. The Port field of the CSV-CSA
record defined in [ID-CSVCSA] can be extended to make signature
related assertions. These assertions could be used to prevent
[RFC2822] FROM from being spoofed.
+--------------+----------------------------------------------------+
| Bit Value | Meaning |
+--------------+----------------------------------------------------+
| 1 | Explicit: All authorized names have specific |
| | CSV-CSA records. |
| 2 | All Messages Signed using DKIM. |
| 4 | HELO/EHLO within signing-domain. |
| - | Other bit values are reserved for expansion and |
| | must be set to zero. This range of values should |
| | be ignored by the recipient when their function is |
| | unknown. |
+--------------+----------------------------------------------------+
Asserting that "all messages signed using DKIM" allows other domain
signatures to be used, but makes an assurance that all messages sent
by the MTA will be signed. Asserting all "HELO/EHLO within signing-
domain" makes an assurance all messages sent by this MTA can be
identified by a parent domain signature.
15. IANA Considerations
There are no IANA considerations in this draft.
16. Security Considerations
Signatures hold the promise of enabling safe and strong methods for
recipients to assert their own policy requirements. Signatures
should be used in conjunction with HELO/EHLO authentication and a
opaque-identifier to provide a low risk, low impact method to improve
the integrity of email messages. Even if consensus can be reached
regarding which mailbox-domain is to be constrained by a path or
signing-domain based authorization list, and this mailbox-domain were
universally checked, this still assumes all systems are secure, for
any resulting conclusion to be valid. There can be no open system
that abates abuse, without the application of reputation or
accreditation. Applying reputations against a mailbox-domain puts
consumers in extreme jeopardy and the email delivery system at risk.
To ensure consumer safety and the integrity of email delivery,
Otis Expires March 10, 2006 [Page 20]
Internet-Draft MASS-Rep September 2005
reputations MUST only be based upon authenticated entities.
The stronger the authentication, the safer the mechanism is for
providers and consumers alike. Signatures can be implemented
unilaterally and are not premised upon adoption of new universally
applied checks. The benefit of complaints being directed to the
appropriate administrator justify the modest costs for signatures.
Signed messages add value for customers, especially when signatures
become a minimum requirement for various services. Rather than being
a method that targets the current behavior of abusers, signatures
offer a real means to ensure the source of a message. The current
[DKIM] proposal lacks a much needed means to eliminate a replay and
DoS attack, but this can be addressed through the inclusion of the
opaque-identifier and conventions establishing the verification of
the HELO/EHLO.
The signature's key sizes should be reconsidered, where support for
512-bit keys should not be required.
The number of key selectors, when both DNS traffic and protective
strategies are considered, don't lend themselves to be used on a per-
user basis, especially for larger domains. Should such use become
common, recipient DNS caches could be overwhelmed with key
information.
In conclusion, signed messages provide excellent protections for both
the MTA administrator and the mailbox-domain owner alike. In
addition, with a persistent identifier incorporated, signatures offer
a means to rapidly abate abuse from compromised sources, even within
large domains. Using a valid signature, rather than an
unauthenticated mailbox-domain, for assessing reputation will not
invite more egregious behavioral changes in criminal activity, nor
raise legal disputes over who should have been held accountable for
abuse.
17. Acknowledgements
Earl Hood has been making several good suggestions, where I
incorporated his concept of including a copy of the RCPT TO as a part
of the message. This was changed to being a hash of the RCPT TO with
the intent of discovering whether the path of the message had
changed. In the same fashion as adding the RCPT TO hash, Earl also
suggested adding a body hash to be able to isolate body content
alteration from header alterations.
18. References
Otis Expires March 10, 2006 [Page 21]
Internet-Draft MASS-Rep September 2005
18.1 References - Normative
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2234] Crocker, D., "Augmented BNF for Syntax Specifications",
RFC 2234, November 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2538] Eastlake, D., "Storing Certificates in the Domain Name
System (DNS)", RFC , March 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3280] Housley, R., "Internet X.509 Public Key Infrastructure
Otis Expires March 10, 2006 [Page 22]
Internet-Draft MASS-Rep September 2005
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3447] Jonsson, J., "Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.1.", RFC 3447,
February 2003.
[RFC3766] Orman, H., "Determining Strengths For Public Keys Used For
Exchanging Symmetric Keys", RFC 3766, April 2004.
18.2 References - Informative
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)",
July 2005.
[ID-BATV] Levine, J., Crocker, D., Silberman, S., and T. Finch,
"Bounce Address Tag Validation (BATV)", September 2004.
[ID-CSV] Crocker, D., Otis, D., and J. Leslie, "Certified Server
Validation (CSV)", February 2005.
[ID-CSVCSA]
Otis, D., Crocker, D., and J. Leslie, "SMTP client
Authorization (CSA)", June 2004.
[ID-Housley-MASS]
Housley, R., "Security Review of Two MASS Proposals",
January 2005.
[ID-email-arch]
Crocker, D., "Internet Mail Architecture", July 2004.
[NIST-Keys]
http://csrc.nist.gov/, "Key Management Guildline, Workshop
Document (draft)", November 2001.
[TWINKLE] Silverman, R., "An Analysis of Shamir's Factoring Device",
May 1999.
[TWIRL] Shamir, A., "Factoring Large Numbers with the TWIRL
Device, Advances in Cryptology - CRYPTO 2003, Springer,
Lecture Notes in Computer Science 2729", 2003.
Otis Expires March 10, 2006 [Page 23]
Internet-Draft MASS-Rep September 2005
Author's Address
Douglas Otis
Trend Micro
1737 North First Street, Suite 680
San Jose, CA 94043
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires March 10, 2006 [Page 24]
Internet-Draft MASS-Rep September 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otis Expires March 10, 2006 [Page 25]