mass D. Otis
Internet-Draft Kelkea Inc.
Expires: August 26, 2005 February 25, 2005
MASS impacts upon reputation
draft-otis-mass-reputation-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 26, 2005.
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 two MASS proposals: DomainKeys
and Identified Internet Mail.
Otis Expires August 26, 2005 [Page 1]
Internet-Draft MASS-Rep February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Improved Reputation Protection . . . . . . . . . . . . . . . . 3
3. Why not PKI for everyone? . . . . . . . . . . . . . . . . . . 4
4. Key size and performance . . . . . . . . . . . . . . . . . . . 5
5. Protection from Denial of Service attack . . . . . . . . . . . 7
6. Preventing the replay attack . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 References - Normative . . . . . . . . . . . . . . . . . . . 9
8.2 References - Informative . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Otis Expires August 26, 2005 [Page 2]
Internet-Draft MASS-Rep February 2005
1. Introduction
Laws governing email policy allow for broad discretion and do not
always prohibit unsolicited commercial email (UCE). Far more
stringent email policies may be demanded by mail recipients, however.
Signatures validated by the DomainKeys or IIM specifications allow
recipients a strong means to ascertain those entities most directly
accountable for policies applied to the message offered. The
reputation of such entities often determine acceptance of messages,
although this is currently largely based upon the authenticated IP
address. Signatures by themselves are not a panacea, and the current
[DomainKeys] and [IIM] specifications create challenges when
attempting to squelch policy breaches, see [ID-Housley-MASS]. In
addition, the overhead required to implement signatures, compared to
the use of an IP address for reputation assessment, require
additional defenses.
Terminology: Terminology conforms to [ID-email-arch].
2. Improved Reputation Protection
Basing reputation on authenticated identities is essential for
fairness as well as the integrity of email delivery. The IP address
or the HELO/EHLO domain name can be authenticated for the purpose of
fair reputation assessment, but this places the MTA administrator in
the path of complaints. This administrator may allow transit of
messages from other domains as a valuable service, but even ensuring
reputations of these other domains still places the task of defending
reputations onto the MTA administrator. Risks for reputation largely
result from compromised systems within originating domains.
One solution being debated is to constrain the IP addresses for a
message's sending mailbox-domain as a promised means to curtail an
often criminal practice of spoofing. This mailbox-domain constraint
offers little assurance this will ultimately be effective and
reliable, being based upon IP address authorization and assumed
intervening security. Furthermore, suggestions for basing reputation
upon the mailbox-domain unfairly shift accountability onto the
mailbox-domain owner, where this required security may be well beyond
the control of the mailbox-domain owner. Such mailbox-domain address
constraints will likely prove disruptive for the consumer and
ultimately expensive for all concerned. Potentially unfair
mailbox-domain reputation assessments will be difficult to rectify
once incorporated silently into email filtering applications. Also,
unauthenticated mailbox-domains as a basis for reputation further
encourages an already significant problem of compromised systems,
making abuse even more intractable.
Otis Expires August 26, 2005 [Page 3]
Internet-Draft MASS-Rep February 2005
A signed message does not suffer from these serious drawbacks and
allows safe assessment of the message source by making no
presumptions of intervening security. A domain level assertion that
all [RFC2822] FROM entities are signed offers a safe means to prevent
mailbox-domain spoofing. As a result, 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. Using a valid signature, rather than
an unauthenticated mailbox-domain, for assessing reputation does not
invite more egregious behavioral changes in criminal activity, nor
raise legal disputes over who should have been accountable for abuse.
3. Why not PKI for everyone?
The relative simplicity of either of these message signing proposals
represents essential elements needed to sustain the performance
demanded by the email infrastructure. While policy enforcement
necessitates cancellation of access rights, signatures also
necessitate 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 review
achieves this 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
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 needing exchanged,
while still providing the same capabilities, would represent 6 orders
of magnitude reduction of data exchanged.
For the smaller providers, not incurring the added expense of
acquiring certificates helps reduce barriers to deployment. 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 acceptance.
While using DNS to distribute keys reduces what could be a
substantial expense, this relatively simple mechanism is not without
Otis Expires August 26, 2005 [Page 4]
Internet-Draft MASS-Rep February 2005
risk.
To confront infrastructure exploitation tactics, by taking advantage
of the DomainKeys approach, keys identified by their selectors could
be signed and verified by using a previous key. The location of
these key signatures could be at the same node as the key records.
The Time-To-Live for these key records should be sufficiently long as
to signal the presences of a possible "hit and run" hijacking
technique. Their cache retention period should fully overlap the
duration of the next key's use. At the receiving SMTP server,
retaining a list of valid selectors could indicate which selectors
are new and in need of checking. This may be achieved by disabling
recursion for selector lookups. When not in cache, a recursive
lookup would then include a check for the validity of a new key
against the selector included within the matching signature's Key
Tag.
Establishing a convention for key selectors as a numeric value with a
range of 0-65,535, which could reflect the week of the year as
example, then a Key Tag as provided in [RFC2538] could indicate which
prior key was used to sign the newer key. The Time-To-Live for keys
would be established to fully cover its own employment and overlap
the period where the next key is employed.
v3._mk.<signing-domain> ; signature of key 00003
(the CERT Key Tag indicates which private half of a public key was
used to create the signature.)
p3._mk.<signing-domain> ; public key 00003 to verify messages.
Noting an instance where an older key is not already captured could
have value in another way. When there is something suspicious,
checking the signatures of the keys could offer a means to detect a
problem. In general, domains without a retained selector offering
high levels of traffic may indicate this domain was hijacked, or
recently acquired. Temporary refusals for a few hours in this
situation could be prudent, to allow time for either a reputation
service to list the domain, or for a possible hijacking to be
resolved.
4. Key size and performance
RSA keys are used by both proposals and, for this review, are assumed
to follow the outline in [RFC3447]. The processing to verifying a
signature is roughly dependent upon square of the key size. The
overhead associated with certificate or key handling is ameliorated
Otis Expires August 26, 2005 [Page 5]
Internet-Draft MASS-Rep February 2005
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 a Moore's law doubling of
performance every 2.5 years, today's system 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
involve advancement of programmable or custom logic, which further
increases the performance factoring by thousands 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 incentives fostering growing
criminal activity to send email to entice victims, these expenses may
not be suitable deterrents. Today's recommended minimum key size of
1024-bits seems well justified, and changes to 2048-bits for the year
of 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 provides 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-bits key and a system 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
Otis Expires August 26, 2005 [Page 6]
Internet-Draft MASS-Rep February 2005
to 1024-bit keys, the resulting overhead should increase by a factor
of about 1.6. Such a machine dedicated to performing this operation
could then handle daily about 4.8 million messages which average 8 KB
in size.
5. Protection from Denial of Service attack
The growth of UCE messages is becoming a significant burden on both
the networks and related servers. Paradoxically, signed messages add
to both the network and server burdens, if not effective at deterring
abuse. To ensure protection of the infrastructure, signature
validation must therefore be performed in concert with a lightweight
mechanism that also offers an authenticated domain name as a basis
for reputation, well ahead of any signature validation operation, see
[ID-CSV]. Why two mechanisms? A blunt lightweight mechanism suitable
for refusing mail from the most egregious cases provides Denial of
Service protections. Message signatures coupled with a
revocation-identifier offers the signing domain a means for a
surgical removal of offensive accounts. With signatures and
revocation-identifiers, no longer must abuse be tolerated simply
because the domain is large.
The lightweight DoS protection mechanism could be based upon a single
DNS lookup to confirm both the authorization and authentication of
the sending SMTP client by applying the EHLO/HELO domain name. When,
by convention, the EHLO/HELO are typically the within the domain that
signs the messages, a few other efficiencies are made possible. (For
providers that offer transit for other domains, arrangement could be
made to allow the forwarding of the EHLO/EHLO.) It becomes possible
to skip a reputation check for the signing domain following a
reputation check of a EHLO/HELO contained within this domain. Most
significantly however, by finding the EHLO/HELO is within the signing
domain, checking to determine the status of a specific
revocation-identifier would not be needed. Had the account been
revoked, it should be impossible for these messages to be signed with
a revoked revocation-identifier.
6. Preventing the replay attack
The revocation-identifier is a mechanism being suggested by this
review. If a persistent identifier were added to an unsigned
message, this would invite forgery and therefore offer little value.
Included within the validated content of a signed message, such
standardization of an identifier offers significant value. It would
be an opaque value added to the signature header that must be valid
as a domain name label. This revocation-identifier would be most
useful when it is a persistent identifier derived from the access
server that authenticates the account being used.
Otis Expires August 26, 2005 [Page 7]
Internet-Draft MASS-Rep February 2005
In such a case, this 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, cracked wireless access points, among many other
nefarious methods. Abuse reports cataloging signed messages and
correlated with the revocation-identifier would provide
incontrovertible evidence where the source of a problem exists. The
publishing of the revocation record for the revocation-identifier
would also provide feedback that measures were taken to rectify a
policy breach.
In odd cases where where the EHLO/HELO are not contained within the
signing domain, a single lookup of the revocation-identifier
returning no record would be an indication this particular
revocation-identifier is still authorized by the signing domain.
This mechanism would be most valuable in those cases where the
message may be 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 most expedient
method 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, their immediate provider!
The construction of this revocation record mechanism could take the
form of a single A record lookup. The actual record might be:
<revocation-identifier>._rl.<signing-domain> IN A 127.0.0.1
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
EHLO/HELO being within the signing domain allows this revocation
check to be skipped. Where the revocation check is made for odd
cases where the EHLO/HELO is within a different domain, this would be
performing nearly an identical lookup now nearly ubiquitously done to
investigate the status of the SMTP client's IP address against an RBL
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. By not
offering a record otherwise, when the situation regarding a
particular identifier changes, cessation of its authorization can be
prompt. The Time-To-Live for negative DNS caching is determined by
the recipient. This allows the recipient to trade-off
Otis Expires August 26, 2005 [Page 8]
Internet-Draft MASS-Rep February 2005
responsiveness, network traffic, and cache size to meet their needs.
7. 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
revocation-identifier to provide a low risk, low impact method to
improve the integrity of email messages. Those who see IP address
constraints for mailbox-domains as "low-hanging fruit," should also
consider the application of reputation upon an unauthenticated
mailbox-domain as "forbidden fruit." 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 added costs for signatures should provide the
reward of complaints directed to the appropriate administrator, and
adding value to their customers, especially when signatures become a
minimum requirement for various transit services. The current
proposals lack a much needed means to eliminate a replay risk, but
this can be addressed through the inclusion of the
revocation-identifier.
The signature's key sizes should be reconsidered and keys sizes as
small as 512 bits should not be allowed.
The number of key selectors, when both DNS traffic and protective
strategies are considered, don't lend themselves to be used on a
per-users basis, especially for larger domains. Should such use
become common, recipient DNS caches could be overwhelmed with key
information.
8. References
8.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",
Otis Expires August 26, 2005 [Page 9]
Internet-Draft MASS-Rep February 2005
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.
[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
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.
8.2 References - Informative
[DomainKeys]
Delany, M., "Domain-based Email Authentication Using
Public-Keys Advertised in the DNS (DomainKeys)", August
Otis Expires August 26, 2005 [Page 10]
Internet-Draft MASS-Rep February 2005
2004.
[ID-CSV] Crocker, D., Otis, D. and J. Leslie, "Certified Server
Validation (CSV)", February 2005.
[ID-Housley-MASS]
Housley, R., "Security Review of Two MASS Proposals",
January 2005.
[ID-email-arch]
Crocker, D., "Internet Mail Architecture", July 2004.
[IIM] Fenton, J., "Identified Internet Mail", October 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.
Author's Address
Douglas Otis
Kelkea Inc.
1737 North First Street, Suite 680
San Jose, CA 94043
USA
Phone: +1.408.453.6277
EMail: dotis@kelkea.com
Otis Expires August 26, 2005 [Page 11]
Internet-Draft MASS-Rep February 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 August 26, 2005 [Page 12]