Keys to the Domain

Available now, DomainKeys is one promising entry into the fight against spam

With new studies showing that one in three online users complain that up to 75 percent of their e-mail is spam, it should be no surprise that serious efforts are underway to deal with this plague. I wrote about one effort by Microsoft, known as Sender ID, in November.

Sender ID, however, is just one of a number of efforts, none of which have become a standard. But whether or not a standard emerges, some form of e-mail sender authentication will be part of Internet e-mail in the future. The advantages of such a design are too rich to ignore. If it's possible to determine that an e-mail was actually sent by the domain from which it claims to be sent, filtering software that rejects spoofed mail (mail claiming to come from somewhere it doesn't, such as phishing) can be developed.

DomainKeys Explained

There are other alternatives out there, too. One promising entry is DomainKeys, available now. Like Sender ID, DomainKeys has been submitted as an IETF draft (available at www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt).

Like Sender ID, DomainKeys hopes to reduce spam by providing a way to identify the authoritative mail servers for registered domains, thus determining whether an e-mail's purported domain is legitimate. Once it's known who really sent the e-mail, the e-mail can then be delivered to the recipient or rejected based on the reputation of the domain.

Authentication guarantees that e-mail comes from whom it says, which aids in identifying phishing attacks; but it still doesn't guarantee the mail isn't spam. Like legitimate senders, spammers also own domains and can certainly register their authorized servers in DNS. If the e-mail comes from a known spammer, companies may wish to reject it. This is the selling point Cloudmark makes with its Rating for Sender ID. They want to help companies weed out known spammers based on their Sender ID authentication. If an e-mail can't be authenticated, it can either be rejected or subjected to other spam-filtering techniques.

DomainKeys requires the use of public key/private key technology, but not certificates or a Certificate Authority (CA). Instead, each e-mail domain will generate a public key/private key pair. The public key will be stored in a DNS.TXT record in the DNS records for its domain, and hence be publicly available. The private key will be made available to each mail server the domain owner authorizes to send mail for the domain. Only the domain owner should have access to the private key, and the private key must be protected. The process of sending and receiving DomainKeys mail is as follows:

• An authorized e-mail server prepares an e-mail for transport. Just before leaving the server, a message digest of the e-mail is created. A message digest is the result of applying an algorithm that produces a unique digest, or signature. No two e-mails will produce the same message digest when the same algorithm is used.

• The message digest is encrypted using the stored private key to produce a digital signature.

• The original e-mail and its digital signature are sent in the normal manner.

• The e-mail is received by the server of the recipient's domain.

• Processes on this server abstract the purported sender domain of the e-mail from the e-mail header information.

• A DNS lookup is used to obtain the public key from the sender domain's DNS records.

• The receiving server makes its own message digest of the e-mail message.

• The receiving server uses the retrieved public key to decrypt the message digest received with the message.

• Both message digests—the decrypted one and the newly generated one—are compared.

• If the message digests match, the e-mail message is authenticated as coming from the legitimate domain. If the message digests don't match, the e-mail isn't authenticated.

• Based on the test results, local policies decide if the mail is delivered to the recipient's inbox, discarded or subjected to other spam filters.

Can DomainKeys Stop Spam?

While no solution is perfect, use of DomainKeys can answer the question "Did this e-mail come from the domain it says it came from?" If, for example, an e-mail claims to be from a financial institution wanting me to update my account, DomainKeys can show the e-mail really comes from that company.

Note, however, that DomainKeys will not determine if a message is really a phishing attack, spam or legitimate mail; it merely provides a way to determine if the e-mail comes from an authorized server from which the domain the e-mail claims to come. Using that knowledge, an e-mail server can be programmed to respond and stop the delivery of anonymous spam.

There is, however, nothing to stop spammers from providing a public key in the DNS records of their own registered domain, and digitally signing their spam. Still, as these domains are identified as known spam sources, mail servers can be programmed to reject mail based on the domain.

A False Sense of Security?

DomainKeys has a weakness: As currently proposed, it doesn't require a Certificate Authority (CA). When public key technology is utilized, a CA often issues, manages and maintains public key/private key pairs and proves that the keys were issued by the responsible party. The CA signs a certificate that includes the public key. Because this signature can be verified (a copy of the CA certificate can do so), organizations have reasonable assurance that the public key, and hence the public/private key pair, did originate with the authorized authority. DomainKeys assumes that only the domain owner will be able to add the public key to the DNS records for the domain, and therefore using a CA to establish trust isn't necessary.

The risk that DNS might be compromised is slight if properly managed and protected by the domain owner; but if an attacker manages to insert a DNS record that contains his own public key, he could digitally sign spoofed e-mail and foil the DomainKeys authentication process. This risk could be mitigated by using a CA. There is no way to prove that a public key included in a DNS record is the one provided by the domain owner. But if a CA-issued certificate containing the domain owner's e-mail public key is placed in the DNS record, it can be validated.

Proponents of DomainKeys argue that only the domain owner controls the DNS, making compromise unlikely. Smaller domain owners may not manage their own DNS, and use an external DNS provider instead. This adds increased risk.

A comparable use of public key/private key pairs for authentication is the use of SSL certificates during Internet purchases. While self-signed (i.e., non-CA using) SSL certificates can be generated and used for SSL sessions, SSL certificates obtained and signed by commercial CAs are more trusted. When used, there's greater assurance that the Web site is run by the company you think it is. If DomainKeys is to work, you must have reasonable faith in the digital keys used to authenticate an e-mail's origin. If the very basis of trust in the DomainKeys process is suspect, it's worse than no authentication of e-mail at all, because those e-mails will be more readily accepted as legitimate.

What Do I Need to Do Now?

At the time of this writing, there's no indication that wide adoption of DomainKeys will happen soon. Still, there's nothing to prevent you from adopting DomainKeys. But unless there are more participants, you'll never reap the full benefits. However, it seems likely that some organizations will benefit by making public keys available in their DNS records for each authorized e-mail server and digitally signing their e-mail. Digitally signed e-mail can be accepted by DomainKeys-compliant e-mail servers; non-DomainKeys-complaint servers can also be used, but the digital signature just won't be used until DomainKeys-complaint software is available. Adopters of e-mail software that can use DomianKeys will benefit by being able to authenticate some e-mail, especially if it comes from business partners, financial institutions and other critical e-mail originators

source http://www.redmondmag.com