The Beginning of the Crypto Era

[R.A. Hettinga]

<http://www.eweek.com/print_article2/0,2533,a=139274,00.asp>

EWeek



The Beginning of the Crypto Era
November 15, 2004

 By   Larry Seltzer
 In a move that was totally expected, if a little early, Yahoo has
announced that it will put its money where its mouth is and start checking
Yahoo Mail with its DomainKeys system.


The company had told me that it would do so by the end of the year, but I
suppose it had had this last week, during the FTC e-mail authentication
summit, as an internal deadline. Earthlink also announced that it will test
DomainKeys on its system.

DomainKeys is important. It is the main implementation of the second of the
two most credible approaches to SMTP authentication, specifically the use
of cryptographic signatures to authenticate messages against the domains
from which they were sent. The other approach-to check against the IP
addresses of the servers in those domains-also moved forward recently with
the second version of the Sender ID spec.

Don't assume that the DomainKeys implementation is the final form. There is
an IETF group called ietf-mailsig working in preliminary stages to
standardize the crypto approach to SMTP authentication and they might want
to make some changes to the approach used by Yahoo. And I expect Yahoo to
be open to such suggestions.

In fact, Yahoo's openness to reasonable suggestions and unobjectionable
licenses is a big reason to be optimistic about widespread adoption of it.
Indeed, while Yahoo has intellectual property claims on its developments in
DomainKeys, the company isn't being a jerk about it, like some other
coMpanieS in this business that shall remain naMeleSs.
There are some interesting questions about DomainKeys and Yahoo's handling
of it. The first has to do with performance. My own first impression of
cryptography as a solution was that the added performance burden on MTAs
(message transfer agents, better known as mail servers) would be great and
that many companies would have to upgrade their hardware to run a
DomainKeys-enabled server with decent performance. In a recent eSeminar in
which I participated, Richi Jennings of Ferris Research echoed this view.

But while it's still too early to tell, there's reason to believe the
performance issue is not as serious as first impressions would indicate.
I've spoken to Sendmail, the leading MTA company in the world, about it.
Nobody, except Yahoo, has more hands-on experience actually testing and
coding DomainKeys than Sendmail. Sendmail thinks the added performance
burden, entirely CPU-based, is on the order of 15 percent to 20 percent.
This isn't nothing, but MTAs aren't typically CPU-constrained-they are
network- and perhaps disk-constrained-so there could easily be spare CPU
capacity in the typical MTA (unless it's running Exchange Server or Notes,
in which case it's CPU-starved).

Next Page:  Why no SPF implementation?

The other question I have about Yahoo is why it has refused to implement
SPF. Sender Policy Framework is the uncontroversial part of Sender ID, the
part that checks the message envelope.

 Many people still argue that SPF is all we really need. But no serious
people believe this, least of all SPF's author Meng Weng Wong, who is a
principal author and sponsor of the Sender ID spec and also a fan of
DomainKeys. All SPF really stops is bounce messages, also known as "Joe
Jobs." It's an important part of the solution, but it's far from an
adequate one.

But it is an easy one, and there's no good technical reason why Yahoo
should resist it. All the other major mail providers, to my knowledge, are
implementing SPF as part of their experimentation. The answer for Yahoo is
probably something as stupid as not wanting people to get the misimpression
that they are hedging on DomainKeys. I asked the company about this several
weeks ago, and it weaseled out of a direct answer. Most dissatisfying.

The Yahoo announcement focuses on phishing, probably because it's topical.
Spam has become a major annoyance, but phishing is scary. And SPF does
nothing to address phishing. This is why Microsoft developed Caller ID, the
header portion of Sender ID.

I should also take a moment to wag my finger at those who continue to
express concern at how spammers are adopting SPF and other authentication
standards in order to get around them. I don't know if they're walking into
a trap or if they're just experimenting, but it won't do them any good. The
more spammers authenticate, the easier they will make themselves to block.
For insights on security coverage around the Web, check out eWEEK.com
Security Center Editor Larry Seltzer's Weblog.

Remember, authentication systems are not complete anti-spam systems. They
just identify who is sending the mail, not why they are sending it. This
whole approach requires the coordinated use of reputation systems that will
use the authenticated address to tell you whether a sender is trustworthy.
In such a scenario, an authenticated spammer becomes easy to block.

The collapse of MARID brought forth a call for experimentation with the
various proposals in the hope that the experience would inform the
standards process and help to produce a consensus. We're lucky. The
experimentation so far has formed along the lines one would expect, meaning
the proposals backed by the major players. The advancement of DomainKeys
puts in an approach that the open-source community won't object to and that
is forward-looking. It doesn't have to be the only success in this area,
but it's good that we have it.

Security Center Editor Larry Seltzer has worked in and written about the
computer industry since 1983.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com