« previous 1 2 3 4 5 6 7 next »

It's all in the header

An encrypted hash and a reference to the key are enough to sign the content of an email (its body). DKIM, however, also safeguards the header against manipulations and is designed to be as flexible as possible even in multilevel mail systems and with email service providers. Therefore, it requires some additional information, and the server adds a "DKIM-Signature" header to the email. If we take a look at this header, the problems and principles of this procedure become apparent:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;
d=example.net; s=mail200801; i=dau@sub.example.net;
h=Date:From:To:Subject:Message-ID:References:Content-
Type:Content-Disposition:Content-Transfer-Encoding;
bh=8FBe8u6BvmKcvYyKlx+oYvPBSj4=; b=I+oWYOxFAk
...
Ajcxdz66BEmd8Mqs9lD2U=

The header contains several fields each consisting of a letter followed by an equal sign and the value. The value behind v= gives the respective version of the DKIM standard; "1" has been used since the RFC was released. a= gives the hash and encryption algorithm.

c= contains information about the "Canonicalisation": while an email is in transit, servers sometimes wrap the text differently, change the capitalisation and insert or delete spaces. This is particularly common practice for making headers more legible. Although such alterations are permitted by the email delivery standard, they would invalidate the signature. If the message is reformatted in the same way both by the sender before signing the email and by the recipient before evaluating it, the signature remains valid. The relaxed value, for example, means that line feeds are to be removed from the headers and several spaces are to be combined into one space. strict, on the other hand, allows no alterations at all. The recommendation is to treat the headers as relaxed while applying strict to the rest of the message (see our example), which is achieved by adding both values separated by a slash.

A DNS query tool can be used by anyone to take a look at the keys that are used for DKIM. d= identifies the domain whose key was used for signing the message. This doesn't necessarily have to be identical with the sender's address stated in the From: header, for example when a mailing list is involved. s= contains a "selector", which is the name of the key. The sender uses this name to deposit the public key in the DNS server's _domainkey subdomain in form of a TXT entry. This way it is easy for recipients to retrieve the key, and no additional key management infrastructure is required. It is also unnecessary for a trusted institution to verify the key's authenticity, as only the sender can add an entry to his or her DNS server.

On the command line, the key can be retrieved using the nslookup -type=TXT mail200801._domainkey.example.net command. At first glance, the returned TXT record looks similar to the signature:

v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0N
...
lK5b7PeJHBv4MejV0G3hwIDAQAB

The fields contain the DKIM version (v=, optional), the key type (k=, optional) and the key itself (p=). Selectors can be used to assign various keys to a domain. The RFC recommends changing keys regularly and invalidating old ones. For this purpose, the TXT record remains in the DNS, but the actual key, that is the part behind p=, is deleted by the admin. Version numbers or dates in the selector make it easy to switch between valid and invalidated keys. The signature covers both the message body and the headers to prevent frauds from manipulating, for example, the From: sender field. To make sure that headers that were inserted during transit or are unimportant don't interfere with the signature, the DKIM header also contains a list of signed fields (h=). This list may also contain headers which didn't actually appear in the email to prevent frauds from adding these headers during transit. The i= field contains the signed-for "identity". This could include the sender's complete details or the (sub)domain the signing server is responsible for. Our example shows that the email address can also belong to a subdomain of the domain entered at d=. The header contains the body hash (bh=) to allow the recipient to detect manipulations even if the public key is unavailable because it has been invalidated or due to a DNS failure. b= finally contains the actual signature.

A matter of trust

A correct DKIM signature shows the recipient that the email passed the server which holds the private key that matches the one published via the DNS. However, a missing signature is only equivalent to a forged email if the sender signs each and every email. While such "policy" information was part of Yahoo's DomainKeys technology, DKIM manages it in a separate RFC which has not yet been ratified. The protocol is to be called "Sender Signing Practices (SSP)" and will determine the handling of messages without or with flawed signatures.

Even without SSP, DKIM guarantees that the email originated from the named sender's domain. The technology is an instant cure for phishing attacks that use principle-based forged sender addresses. However, the first signed spam emails, for example from Yahoo or Googlemail addresses, have already appeared. Therefore, a correct signature is not sufficient as a filter criterion; the postmaster must also assess whether a DKIM validated domain is a likely originator of spam. The standard itself doesn't deal with this question as it is a matter of good reputation, rather than a technical issue. Thanks to DKIM, admins can allow known senders to bypass the spam filtering process. What's missing, however, is a technique that takes into account an unknown sender's reputation. Karmasphere is a first attempt to gather this kind of information and make it available in machine readable form.

« previous 1 2 3 4 5 6 7 next »