June 21, 2006
This article was contributed by Jake Edge.
Last week, this page
described
Sender Policy Framework (SPF) and some of its shortcomings. A different
technique with similar goals is
Domain Keys (DK) which
appears to be gaining support. This week, DK will be examined along with the
related
Domain Keys Identified Mail
(DKIM) proposal.
DK was
proposed
by Yahoo as a way to authenticate the sender of an email. Essentially, the
email is signed using a public key cryptographic signature. A receiving
Mail Transfer Agent (MTA) or Mail User Agent (MUA) can look up the public
key in the DNS record for the sending domain and compute the signature.
If it matches the entry in the DomainKey-Signature header, the email has
been verified to have come from that domain.
The DK header can specify which other headers are signed and the email body
is always included. The domain in the "From:" (or, in some cases, "Sender:")
header must always match the domain in the DK header and that provides the
linkage that verifies the sender. Because of the way the signature algorithm
works, any modification to the signed parts will result in a signature
mismatch -- this provides some email integrity protection.
Domains and subdomains will maintain public keys as TXT records in their
DNS entries. DK uses a standard section of a domain's DNS space to contain
the public keys for that domain. In addition, a selector is specified in
the DK header which can be used to restrict keys to specific organizations
and to revoke keys periodically. To retrieve a key, one queries for the
TXT record associated with selector._domainkey.example.com.
DK has been adopted by two of the larger email providers: Yahoo and Gmail.
Banks and other financial institutions are also starting to adopt it because it
provides very good phishing protection for their customers. It allows
customers the opportunity to verify that the mail is authentic.
Unfortunately, the support for DK checking in MTAs and MUAs has not been
widely deployed yet, but the early adopters appear to be betting that it will be.
There are several issues with DK, but they do not fundamentally break the
store and forward nature of email as SPF does. The main problem
is that users will need to use an SMTP server associated with the domain
that they are sending from or their MUA will need to generate a DK
signature using a personal private key (that is listed appropriately in the
domain's DNS). Another issue is that the signing of the
body only works if the body is not modified after the signing. Unfortunately
some mailing lists and other software (virus scanners for example) tack on
a few lines to the body and this will cause the signature check to fail.
A potentially bigger problem is that DK is covered by patents held by Yahoo.
Microsoft's Sender ID
proposal never gained any traction in the free software world because of
patent issues, but it appears that Yahoo's liberal licensing terms have
removed that issue, at least for free software. Yahoo licenses the patents under either the GPL or their own
license
agreement. A patent peace provision and a notice that acknowledges
Yahoo's intellectual property are all that are required for those who do
not wish to license under the GPL.
Shortly after Yahoo released the Domain Keys specification, Cisco proposed
Identified
Internet Email. The two are similar in many respects and have since
been merged into a
proposal
called Domain Keys Identified Mail (DKIM). The
IETF has formed a DKIM working group that plans to guide the proposal
towards adoption as an internet standard. Depending on whose opinion you
believe, that could happen within the next year or two. It remains to be
seen whether there is widespread adoption and conversion from Domain Keys
if and when DKIM becomes a standard.
Comments (11 posted)
