ŠĀmass D. Otis Internet-Draft Kelkea Inc. Expires: September 23, 2005 March 25, 2005 MASS impacts upon reputation draft-otis-mass-reputation-01 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 September 23, 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 MASS proposal: DomainKeys. Otis Expires September 23, 2005 [Page 1] Internet-Draft MASS-Rep March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security and Email Policy . . . . . . . . . . . . . . . . . 3 3. Filtering erodes integrity . . . . . . . . . . . . . . . . . 4 4. The next steps in policy enforcement . . . . . . . . . . . . 7 5. PKI certificates per user would burden larger domains . . . 8 6. Key size and performance . . . . . . . . . . . . . . . . . . 10 7. Protection from Denial of Service attack . . . . . . . . . . 12 8. Abating the replay attack . . . . . . . . . . . . . . . . . 13 9. Border Validation . . . . . . . . . . . . . . . . . . . . . 15 10. Domain Assertions for Signatures . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1 References - Normative . . . . . . . . . . . . . . . . . . 18 12.2 References - Informative . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Otis Expires September 23, 2005 [Page 2] Internet-Draft MASS-Rep March 2005 1. Introduction Laws governing email policy allow for broad discretion and do not always prohibit unsolicited commercial email (UCE). However, far more stringent email policies may be demanded by mail recipients. Signatures, validated by keys published within DNS, allow recipients a stronger 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 currently this is normally based upon the IP address. Signatures by themselves are not a panacea, and the current [DomainKeys] specification 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, requires additional defensive measures. Terminology: Terminology conforms to [ID-email-arch]. 2. Security and Email Policy Systems suffering a security breach have become a primary means for sending abusive email. Any scheme that attempts to abate abusive email traffic must seek to identify actual sources for determining those accountable for maintaining security when abuse is discovered. Ensuring the validity of these identifiers requires authentication, especially when used as a basis for network protection. Any 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 would be both expensive and ineffective to abate abuse or maintain security by having each recipient contemporaneously establish permissions. Creating additional protocol requirements will not abate email abuse either, as those wishing to abuse email will be among the first ones to employ such newer requirements, once they offer greater access. Pooling a community's experience is an effective long-term policy enforcement technique when confronting these many sources. This pooling or centralization is often accomplished through reputation services as a means to establish policy within a community, where those with even a brief history of not adhering to these policies are thereby excluded from the community. Real-time black-hole lists have become a commonly used mechanism to publish reputations, where no record returned indicates a good reputation. A Otis Expires September 23, 2005 [Page 3] Internet-Draft MASS-Rep March 2005 community wishing to enforce an Opt-In requirement for bulk email, as an example, often employs an email reputation service to establish such a 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 messages 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 as well. Some bulk email distributors also utilize a vouching or accreditation service which attests their compliance to specific policies. Such accreditation requires that the recipients use and trust this 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 a record may also assert favorable ratings. Such fee structures for accreditation may provide senders greater latitude, and tend to dissuade typical domain administrators, who then ignore such accreditation services. More recipients may use an accreditation service, if there were a standardization for the response records and a method for the sender to recommend services. Larger providers may utilize accreditation services together with their own white-listing for bulk email distributors, as an adjunct to real-time black-hole listings. White-listing by IP address is difficult to scale, but this is employed for bulk distributors when their volumes lead filtering algorithms to categorize them as abusers. Hopefully, reliance upon message signatures and technologies such as Really Simple Syndication, RSS, will soon serve as viable alternatives to white-listing for the bulk distribution of information. Signatures should depreciate reliance upon filtering, and adoption of RSS inherently allows the recipient to create their own permissions. RSS could be fostered by being utilized as feedback for commercial transactions. 3. Filtering erodes integrity Filter programs often hide their actions, and this inhibits challenges by senders. The ability to challenge is needed 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, it may be due to a phrase contained within the message. A doctor's reply to a patient may be steadfastly rejected regardless which provider is used. Unfortunately, many of Otis Expires September 23, 2005 [Page 4] Internet-Draft MASS-Rep March 2005 these filter programs have evolved to also silently discard messages, once some level of heuristics has been achieved. As a result of the breakdown in policy enforcement, the resulting reliance upon filters, which silently discard, as well as place messages into the often ignored "Junk" folder, greatly reduces the integrity of email delivery . Those, wishing to improve upon filtering, claim mailbox-domain path registration using IP address lists will reduce reliance upon content. An often espoused feature is that such path registration will thwart phishing and spoofed bounce-address techniques. Lack of consensus regarding which mailbox-domain is constrained makes this claim specious. There is often a high premium willing to be paid to assure delivery of commercial transactions. These transactions are also most often affected by phishing, but the strict listings that are suggested to affect phishing are incompatible with reliable delivery. Many headers may serve to qualify a message for acceptance, but then the mailbox-domain used as a basis for acceptance may remain unseen by the user. Email that conforms to a prescribed path still offers little protection for users deceived by what they are able to see. Path registration anti-spoofing or anti-phishing claims, even with strict listings, are dangerous by creating false assurances. More importantly, publishing these path registration address lists increases the risk of misapplied reputation by those who assume MTA authorization is equivalent to the mailbox-domain having been authenticated. A non-strict list permits any source to send messages using the mailbox-domain. This non-strict approach accommodates forwarding by recipients, or some types of list servers, for example. Such lists also permit anyone sharing the MTA to send messages that will appear to be fully qualified for acceptance. Even strict lists still permit the mailbox-domain to be forged. The sending MTA administrator may ensure the bounce-address is not misused, but the recipient might not use the bounce-address and qualify headers instead, which circumvents the sending administrator's protection of the bounce-address. Patent licensing issues may constrain the sending MTA administrator from also making assurances beyond the bounce-address. Applying reputations to mailbox-domains falsely presumes authentication and intervening security. Path registration for a mailbox-domain offers only MTA authorization and is comparable to content filtering based upon weak identifiers. Although it may take time, expect these false assumptions to be fully exploited. As an analogy, consider that an automobile represents the MTA, the driver represents the administrator, who's name represents the MTA HELO. The Vehicle Identification Number (VIN) identifies the vehicle owner Otis Expires September 23, 2005 [Page 5] Internet-Draft MASS-Rep March 2005 and represents the MTA IP address. A passenger represents the mailbox-domain owner, and removable front and rear license plates, that identify the passenger, represent the mailbox-domains. The vehicle owner, driver, and passenger may be one in the same, but typically these are different individuals, as with a prevalence of taxis in some cities. Passengers mount both the front and rear license plates before entering the vehicle. After the passenger enters, the driver may check which plates have been mounted before proceeding. A contract is required before the driver can check the larger rear plate, and therefore the rear plate may not always be checked. The driver may also be lax and fail to check any plate. The city is suffering from an excessive number of illegally parked automobiles, where in the typical case, the offending vehicle would also have a stolen plate. Stolen front plates often deceive parking attendants into directing automobiles to available spaces. In an effort to constrain the use of the plates, passengers are asked to register the authorized VIN of one or more automobiles they may use. As example, a plate's registration may include all the VINs for automobiles owned by Big-City and Small-Town Cab companies. To encourage plate registration, parking tickets will be written against either the front or rear plate, rather than against the VIN of the automobile, as is the current practice. By using the transient plate to assign accountability, the purported passenger (plate owner) will be held accountable. This strategy places the plate owner at risk for several reasons. In the case where a passenger deceives the driver, public plate registrations allow this dishonest passenger to know which plates are associated with the vehicle to further evade detection by drivers that also check the plate's registration. In addition, the driver may be lax or unable to check the mounted plates, where some passenger may be using the wrong plates while wanting to park at inappropriate destinations. Although it is the driver who is most able to ensure security, and who checks the passengers granted access to the automobile, and who monitors the receipt of parking tickets, ticketing against the VIN assumes it is the vehicle owner that controls who is driving. By ticketing against either the driver or vehicle owner, those that ultimately control access would be held accountable. However, in this analogy of path registration, it is the hapless plate owner (purported passenger) that is held accountable. Drivers may rejoice they are not held accountable, but this will certainly lead to abuses harming the majority that are only passengers. It would be impractical to suggest everyone should drive. Otis Expires September 23, 2005 [Page 6] Internet-Draft MASS-Rep March 2005 Checking the plates takes time and may require the driver to interact with passengers. Rather than holding the driver or vehicle owner accountable, it is now the plate owners that must ensure drivers adhere to good practices. But how will the plate owner even know which driver caused them to receive erroneous tickets or which drivers have obtained contracts for checking the rear plate? The driver may have logs, but the plate owner will not have access to these records out of privacy concerns. Even the tickets will not illuminate which driver permitted plate misuse. The plate owner may remain unable to restore their parking record or to discover which driver was negligent. Such a system that holds the passenger accountable is inherently unfair since it is the driver who controls access, is expected to check the plates, and operates the vehicle. 4. The next steps in policy 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 spoofed bounce-addresses 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, and a much stronger message signature. Authentication of these identities provides a means to fairly assess these sources for possible abuse. The IP address and HELO-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 Otis Expires September 23, 2005 [Page 7] Internet-Draft MASS-Rep March 2005 authenticated HELO 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 can be validated within a single DNS lookup. It would also be possible to combine the HELO authentication and authorization with the query to a reputation service by including the HELO domain and the client IP address within the request. 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. DNS protections can be enhanced by providing a means to verify that the sequence of signature keys is valid. 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 abusively repeated beyond the signing domain's control. As a defensive measure, when needed, a message signature also permits inclusion of an opaque revocation-identifier. The revocation-identifier would both ease correlation of abuse, and enable a means to squelch "replay attacks." For example, when the key remains valid for two weeks, publishing a revocation record within minutes of an abuse report would reduce replay exposure by a factor of 4000 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. Adding a domain level assertion that all [RFC2822] FROM entities are signed offers a safe means to prevent mailbox-domain spoofing or phishing. 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. 5. PKI certificates per user would burden larger domains The relative simplicity of the DomainKeys 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 necessitate a Otis Expires September 23, 2005 [Page 8] Internet-Draft MASS-Rep March 2005 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 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 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. To confront infrastructure exploitation tactics, and to take advantage of the DomainKeys approach, new signature keys, identified by their selectors, could be signed with the same method as used for a message. The key signature is then published in the same manner as the key within the DNS. The new key signature could then be verified by using a previous key. The location of the key signatures would be at the same node as the key records. The Time-To-Live for the key records should be sufficiently long to allow their cache retention periods to 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 are in need of checking. Identifying new keys 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. This key checking process could be offered by reputation services as a temporary warning. Otis Expires September 23, 2005 [Page 9] Internet-Draft MASS-Rep March 2005 Establishing a convention for key selectors as a numeric value with a range of 0-65,535 would then be compatible with a Key Tag, as provided in [RFC2538]. A numeric Key Tag, added to the key header, such as v=, would indicate which prior key was used to sign the newer key. v3._dk. ; signature of key 00003 (the CERT Key Tag indicates which private half of a public key was used to create the signature.) p3._dk. ; public key 00003 to verify messages. This example uses _dk rather than _domainkey to conserve the DNS reply. 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 as bad, or for a possible problem to be resolved. 6. 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] Otis Expires September 23, 2005 [Page 10] Internet-Draft MASS-Rep March 2005 +----------+-------------+--------+-------+--------+ | 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 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. Otis Expires September 23, 2005 [Page 11] Internet-Draft MASS-Rep March 2005 +--------------+----------------+-------------+ | 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. 7. 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, if not effective at deterring abuse, will add to both the network and server burdens. To ensure protection of the infrastructure, signature validation must be performed in concert with a lightweight mechanism that also offers an authenticated domain name as a basis for reputation validation. This must be done ahead of message transfers and any signature validation operation, see [ID-CSV]. This mechanism, used in conjunction with a reputation service, can eliminate most DoS attack vectors. Path registration records catalog all outbound MTAs of a domain and demand a minimum of one hundred DNS lookups, while also ignoring UDP exponential back-off. Such path registration records can not offer network resource protection. A quick and lightweight mechanism for authenticating the HELO domain that is checked against a reputation service, would be suitable for refusing mail from egregious abusers and provide Denial of Service protections. A domain reputation service used with the HELO could also be used with the signature domain, where sub-domains of a domain with a bad reputation will also be reported as bad. Message signatures, coupled with a revocation-identifier, also offer the signing domain a lightweight means to defeat abusive accounts that are staging replay attacks. With signatures and revocation-identifiers, resources can be protected, and abuse need not be tolerated simply because the domain is large. Lightweight DoS protection mechanisms should be based upon a single DNS lookup to confirm both the authorization and authentication of the sending SMTP client for the HELO domain name. When, by convention, the HELO is typically within the domain that signs the messages, then a few other efficiencies are made possible. (For providers that offer other domains transit, arrangements may be made Otis Expires September 23, 2005 [Page 12] Internet-Draft MASS-Rep March 2005 to allow the forwarding of the HELO.) It becomes possible to skip a reputation check for the signing domain following a reputation check of a HELO that is contained within this domain. Most significantly however, by finding that the HELO is within the signing domain, checking 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. 8. Abating the replay attack One technique could require signed messages to be from an MTA with an authenticated HELO within the domain of the signature. Another technique may extend this by allowing signed messages to be from an MTA authorized by a list of trusted servers. Both techniques would be comparable solutions that unfortunately will reduce the integrity of email delivery. List servers that pass messages unaltered, or recipients that employ forwarding accounts would be fairly common scenarios that confound such schemes. Deterring the replay does not require all abusive messages to be stopped. There must be a way to rapidly respond to expose and reduce the profits of this abusive behavior. The revocation-identifier is a mechanism being suggested by this document. If a persistent identifier were added to an unsigned message, this would invite forgery and therefore offer little value. A standardized revocation-identifier, included within the validated content of a signed message, would offer significant value. It would be an opaque value added to the signature header that would be valid as a domain name label. A persistent revocation-identifier would be most useful when derived from the access server that authenticates the account being used. In such a case, the revocation-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 revocation-identifier would provide incontrovertible evidence of where the source of a problem exists. The publishing of the revocation record for the revocation-identifier would also provide feedback that actions were taken to rectify a policy breach. In odd cases, where the HELO is not contained within the signing domain, a single lookup of the revocation-identifier returning no record would be an indication that this particular revocation-identifier is still authorized by the signing domain. This mechanism would be most valuable in those cases where the Otis Expires September 23, 2005 [Page 13] Internet-Draft MASS-Rep March 2005 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 most expedient domain able 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 revocation-identifier would be composed of 1 to 63 characters and select a record in this fashion: Within the signature header, a parameter u= would indicate the use of a revocation-identifier. ::= [ [ ] ] ::= | ::= | "-" ::= | ::= %x41-5A / %x61-7A ::= %x30-39 ._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 HELO being within the signing domain allows this revocation check to be skipped. When a revocation check is made for the odd cases of the HELO being within a different domain, this 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, by not offering a record, when the situation regarding a particular identifier changes, cessation of its authorization can be prompt. 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 Otis Expires September 23, 2005 [Page 14] Internet-Draft MASS-Rep March 2005 field, depending upon the recipient's implementation. 9. 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 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" | "DK" | "RDNS" | "A-RR" result := authen "/" author "/" policy "/" time "/" hash authen := "VALID" | "INVALID" | "UNKNOWN" | "ERROR" author := "VERIFIED" | "MISSING" | "UNKNOWN" | "ERROR" policy := 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]. "DK" refers to the procedures defined in [DomainKeys]. "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 Otis Expires September 23, 2005 [Page 15] Internet-Draft MASS-Rep March 2005 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 [DomainKeys] 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 has prevented a determination. 10. 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. | | 4 | All Messages Signed by HELO domain. | | 8 | FROM Signed by HELO 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" allows other domain signatures to be used, but makes an assurance that all messages sent by the MTA will be signed. Asserting all "messages signed by HELO domain" makes an assurance all messages sent by this MTA can be identified by a parent domain signature. The "FROM Signed by HELO domain" assertion indicates that [RFC2822] FROM headers with a mailbox-domain being a parent of the HELO domain must be signed by the parent domain or should be refused. This mechanism provides a means to prevent phishing and should be selectively used by only those experiencing the phishing problem. This assertion may cause messages that have been been altered, or re-signed by other domains, to be refused. Otis Expires September 23, 2005 [Page 16] Internet-Draft MASS-Rep March 2005 11. 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 authentication and a revocation-identifier to provide a low risk, low impact method to improve the integrity of email messages. Even if consensus could have been reached regarding which mailbox-domain is to be constrained by a path registration list, and this mailbox-domain is checked universally, 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, 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 [DomainKeys] proposal lacks a much needed means to eliminate a replay attack risk, but this can be addressed through the inclusion of the revocation-identifier. 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. Otis Expires September 23, 2005 [Page 17] Internet-Draft MASS-Rep March 2005 12. References 12.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. Otis Expires September 23, 2005 [Page 18] Internet-Draft MASS-Rep March 2005 [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. 12.2 References - Informative [DomainKeys] Delany, M., "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", August 2004. [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 September 23, 2005 [Page 19] Internet-Draft MASS-Rep March 2005 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 September 23, 2005 [Page 20] Internet-Draft MASS-Rep March 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 September 23, 2005 [Page 21]