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. ; signature of key 00003 (the CERT Key Tag indicates which private half of a public key was used to create the signature.) p3._mk. ; 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: ._rl. 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]