-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <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@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' -----BEGIN PGP SIGNATURE----- Version: 1308 iQA/AwUBQZpjVMPxH8jf3ohaEQJJKwCgi1SpEnUCBsoXyXRVKX0O1pyltdkAoKat BGbyLClwxL8k4hHIlcdZ7xB4 =jRYJ -----END PGP SIGNATURE-----