Case study on the perils of identity federation
Posted: January 21, 2011 Filed under: identity, Internet, risks, Security Leave a comment »This forceful critique (to put it mildly) of OpenID from a website/business owner perspective highlights one of the main leaps of faiths involved in federation: taking a dependency on a third party for the well-being of your own business.
There is a lot going on in the debacle described in the original post. Some of them could be attributed to “implementation issues,” the vague catch-all category that is the equivalent of “pilot error” we fall back on to explain away incidents without attributing a systematic cause: JanRain randomly changing APIs without proper communication, Google changing the identifier returned, inconsistency between user profiles returned by different OpenID providers etc. These are not supposed to happen– better change tracking could have prevented some of the bone-headed mistakes involved. Instability of the OpenID standard and general lack of interoperability among implementations is an unfortunate outcome of the highly politicized standards process that results from reluctant bringing together avowed enemies to the negotiating table. (Inexplicably the US government has decided to throw its weight behind this already hobbled standard, by empowering the Nationals Institute of Health to work on a pilot program for federal adoption.) But again this is business as usual in trying to forge consensus for Internet standards, and not intrinsic to the problem of OpenID in particular or interoperability in general.
At the same time there are deeper issues at play, and these are inimical to any identity federation scheme . To quote the metaphor used by the original author:
[...] of all the failure points in your business – you really don’t want the door to be locked while you stand behind the counter waiting for business. No, let me rephrase that: you don’t want the door jammed shut, completely unopenable while your customers wait outside – irate that you won’t let them in.
Put simply, when users login to your website using a third-party identity provider (“IDP”) your business is at the mercy of that provider. If they experience a service outage, users can not login to your website either. If they decide to experiment with brand new user interface that confuses half the users, your website loses traffic.
Some of the risks can be mitigated contractually. For example the IDP could commit to a particular service level agreement, saying they have an expected uptime of 99.99%. But no IDP in existence is willing to shoulder the burden of full liability for losses incurred at relying party sites. Your website can make a compelling case that the inability to authenticate new users for an hour has resulted in loss of a thousand dollars, going by historic traffic patterns. The most you are likely to get out of the IDP are profuse, heartfelt apologies and at best a refund for that month. The incentives are highly asymmetric.
One could argue that specialization and economies of scale will compensate for this: JanRain is presumably handling authentication for thousands of web sites. So they are in a position to invest in very high-reliability infrastructure and maintain strong security posture. In principle then they are less likely to experience an outage (compared to what each relying party is capable of) less likely to get breached in an embarrassing manner as Gawker recently managed to, and more likely to respond to security incidents quickly in the worst case scenario. On the other hand, as probabilities for catastrophic failure decrease, the damage potential from that failure is going way up. An outage or breach at JanRain impacts not just the author of that blog post, but every other business using the OpenID interop service. More importantly, this is not a linear function of number of users: scale attracts scrutiny, both from white hat researchers and black-hats looking to capitalize on a lucrative target.
The above scenario only considered unintentional outages. What about cases where service is withheld on purpose? Presumably the IDP is getting paid by the site for their service. What happens when it is time to renew the contract? What if negotiations with the IDP go south and they decide to hold your users “hostage,” by refusing to authenticate them to any RP except yours until you agree to the higher price? If users are only known by their external identity, it is going to be very difficult to reestablish the link. The article quoted above describes the escape hatch required: collecting email address from users, so they can be authenticated independently, presumably by verifying their email. Of course that obviates one of the arguments for OpenID, namely individual websites no longer have to worry about the complexity and cost of operating their own authentication system. It turns out this is what the original post concluded, changing the site to nudge new users to their in-house authentication system instead of promoting OpenID.
CP
Stuxnet and collateral damage
Posted: January 19, 2011 Filed under: Internet, policy, risks, Security Leave a comment »To update von Clausewitz’s maxim for contemporary times: “Malware is the continuation of politics by other means.” This is one of the lessons from the ongoing Stuxnet debate: targeted computer attacks has become part and parcel of nation states’ arsenal in carrying out foreign policy objective.
There have been solid technical analysis of Stuxnet’s complex inner workings, but the debate on policy implications is starting in earnest now. One question that has been overlooked is the extent of collateral damage tolerable from carrying out this type of attack.
Stuxnet was the odd combination of both being targeted very precisely and casting an extremely wide net. The malicious payload that infected industrial controllers only kicked into gear when it detected a very specific environment, believed to represent the uranium enrichment plant operating in Iran. On the other hand, because the software development for such critical facilities typically takes place behind air-gapped networks, the worm had to be released into the wild. Its humble beginnings were no different than the self-propagating malware that wreaked havoc in the past: Code Red, Nimda, Blaster, Slammer, … Except Stuxnet was light-years ahead of its predecessors in terms of sophistication and sheer number of different vectors used to infect new targets.
Because it was after a very specific target that would not be reachable directly from the Internet, the designers threw the kitchen sink at the problem, including an exploit that allowed the malware to propagate by USB drives between machines. This meant Stuxnet would eventually reach places that vanilla malware does not, including compartmentalized networks that been assumed to be isolated from the warzone that is the Internets. Stuxnet was designed to explore every nook and cranny in that space, in pursuit of its ultimate target, the programmable logic controllers destined to spin enrichment centrifuges. Given its non-discriminatory approach to spreading, it is surprising that most of the infections remained contained in Iran, with a smaller number in Indonesia and India– countries starting with “I” apparently did not fare well. By comparison the number of infections in the US were not significant. The first question then is what other systems are “fair game” on the way to reaching an objective. Stuxnet case is complicated by the fact that the presumed target is not directly reachable. Intermediate stepping stones are required to get there, which may end up being personal computers, Internet cafes, anything that is ultimately connected to the persons of interest in some unexpected six-degrees-of-separation logic. (This brings to mind the quote from Robert H. Morris Sr: “To a first approximation, every computer in the world is connected with every other computer.”) Worse the connections are not known in advance: it is a massively parallel search, exploring every possible path along the way in hopes that one may cross paths with the actual target. Such expansive views on scope risk turning every machine in the world into collateral damage in the name of reaching the destination.
The second dimension concerns damage. On most machines it infected, Stuxnet did nothing but propagate to other targets. Again there is a similarity to the massive worm outbreaks of good old days– with the exception of Witty, most contained no malicious payload. Even if it happened to land on a computer where some unlucky engineer had been tasked with developing software for industrial controllers for an unrelated industry, the tampered product would likely have worked flawlessly for its intended environment. This is not to say that there was no cost to Stuxnet for those in its path: there is still time and productivity wasted on removing the malware from the system, both for individuals and companies. On the other hand, economic impact for software vendors is murky. Antivirus vendors benefit from trumping up scare stories. This one fits the bill perfectly, complete with cloak-and-dagger nation state implications. Similarly it is difficult to argue that MSFT suffered great expense in addressing the vulnerabilities implicated in Stuxnet, considering their leisurely patch schedule in the presence of known 0-days.
In any case, it is misleading to focus on the designers’ intent in not harming systems– far from being a magnanimous gesture on their part, it was simply following best-practices in malware design. Noisy/buggy malware is the one that gets noticed and removed. Stealth is a survival strategy: even run-of-the-mill keystroker recorders designed to be steal credit cards in the name of petty theft strive to be very stable. Vandalizing user data, blue-screening the system or displaying in-your-face popup advertisments is the surefire way to get your malware noticed by an AV vendor. (Interesting enough Stuxnet was noticed by Kaspersky and filed away as vanilla malware a full year before its inner workings were properly understood.) The problem is that modern operating systems are incredibly complex, and it is not possible to ensure that malware lives up to its promise of zero collateral damage. When Robert Morris Jr. released the Internet worm, he intended it to propagate only, with no malicious payload and barely noticeable load on infected systems. But a slight miscalculation/bug in the logic caused it to overwhelm networks and machines. Even MSFT can not ship software updates without breaking users in some unexpected, obscure configuration– and they have much higher Q&A expertise and test matrix then organizations developing malware.
The network infrastructure has long been a battle ground, with participants of every scale from hobbyist vandals to organized crime groups and nation states, duking it out with packets. The question raised by Stuxnet is whether these frontlines will expand to includes the machines owned/used by ordinary citizens, turning them into dispensable pawns in pursuit of an elusive objective.
CP
MD2: hash-collision scare of the day
Posted: September 24, 2009 Filed under: cryptography, oped, risks, Security 2 Comments »Overshadowed by the far more serious X509 parsing vulnerabilities disclosed at BlackHat, one of the problems noted by Dan Kaminsky et al. was the existence of an MD2-signed root certificate.
On the surface it looks bad. If MD2 preimage collision is possible, an enterprising attacker could forge other certificates chaining up to this one, and “transfer” the signature from the root to the bogus certificate, complements of the MD2 collision. Root certificates are notoriously difficult to update– Verisign can not afford (for business reasons, even if it is the “right thing” for the Internet) to risk revoking all certificates chaining up to the root. Re-publishing the root signed with a better hash function is a noop: the existing signature will not be invalidated. Only option is to not trust any certificate signed with MD2 except for the roots.
But looked from another perspective, the MD2 problem is tempest in a teapot. Luckily no CA is using MD2 to issue new certificates. (At least as far as anyone can determine– CA incompetence is generally unbounded.) This is important because the MD5 forgery from last December depended on a bone-headed CA continuing to use MD5 to sign new certificate requests. That means a second preimage collision is necessary; simple birthday attacks will not work. Finding a second message that hashes to a given one is a much harder problem than finding two meaningful, but partially unconstrained messages that collide.
Eager to join in the fray against PKI, the researchers point to a recent result, An improved preimage attack on MD2, to argue that such a possibility is indeed around the corner. It turns out the feasibility of this attack and the 0wnership of MD2 was slightly exaggerated, to paraphrase Mark Twain. The paper in fact does quote 2**73 applications of MD2 hash function as the amount of time required to find a second pre-image. This is an order of magnitude above what any previous brute-force attack has succeeded in breaking but Moore’s law can fix that. What the paraphrase seems to have neglected is a far more severe resource constraint, stated bluntly in the original paper and mysteriously neglected in the Kaminsky et al summary: the attack also requires 2**73 bytes of space. Outside the NSA nobody likely has this type of storage lying around. None of the existing distributed cryptographic attacks have come anywhere near this limit– in fact most of them made virtually no demands on space from participants. To put this in context, if one hundred million people were participating, each would have to dedicate more than a thousand terabytes of disk space. Not happening. This does not even take into account the communication and network overhead now required between the different users each holding one fragment of this massive table as they need to query other fragments.
CP
New York Times badly confused on identity management
Posted: August 12, 2008 Filed under: identity, Internet, MSFT, oped, review, Security Leave a comment »Goodbye Passwords is that rare misstep form the otherwise consistently solid Digital Domain section in the Sunday NYT: confused, misinformed and way off base. Among the several muddled arguments, four of them stand out:
1. Equating OpenID to passwords.
“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site.”
Minor factual error: actually the password is not being typed into a random website. It is supposed to be provided only to the website where the identity was originally created, not the website where it is being used. But the general difficulty of determining whether one indeed starting at the authentic site instead of a fraudulent replace– especially when the user has been sent there by the “someone else’s Web site” in question leads to the standard critique of OpenID as increasing phishing risks.
Major factual error: OpenID is a federation standard, not a new user authentication approach. It does not mandate passwords or any other scheme for verifying identity. Open ID 2.0 specification is loud and clear on this point:
“Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification.”
That means the identity provider can choose to use good old-fashioned passwords, smart-cards, biometrics or experimental approaches such as reading tea-leaves to authenticate the user; OpenID is silent on this. In fact one of the more hyped extensions to the protocol, added at the urging of MSFT which has been desperately trying to promote CardSpace, is a way for signaling to websites that the user authenticated with credentials resistant to phishing– Infocards in the original vision that carved out this niche case, but also more generally strong authentication mechanisms such as PKI capable smart-cards.
2. Narrow definition of single sign-on:
OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.
In the most general sense, single sign-on refers to one identity being valid for accessing multiple systems. This is in contrast to the current state of affairs on the web: most websites have their own notions of user identities, requiring users to create a new account. Each account is valid at exactly one website and not recognized anywhere else. Single sign-on (“federation” using the fashionable term) is about merging these disconnected islands of identity such that the scope of an identity can extend beyond that one site.
Quick peek at the Wikipedia entry would have hinted that SSO is not tied to passwords. So it comes as surprise that a Microsoft architect is quoted as criticizing SSO. Cardspace is an instance of single sign-on: the vision calls for one identity held by the user’s machine to be usable for logging into any number of websites. Inside the enterprise, Active Directory is single sign-on because it allows the same credentials to be used for accessing everything from logging into a workstation with the three-finger salute to accessing email or HR systems.
3. Misconception that “information card” is a generic term-of-art as it relates to identity management. Information card, or infocard to use the original name for the technology before it was rebranded into CardSpace, is a particular proposal that defines specific formats and protocols for identity management. Writing about “the information cards” makes about as much sense as writing about “the Facebooks” and “the Googles.” Each is a specific incarnation of a general concept: a social networking site, a search engine and an identity management protocol.
4. No hint of the history of strong authentication or alternatives. A reader may walk away from this article with the impression no realistic alternatives to passwords existed until Cardspace magically burst on the scene. Basic fact checking would have unearthed some not entirely obscure facts: there is a concept of digital certificates dating back to the 1970s, leveraging the same brew of “hard to break cryptography” whose virtues are extolled in the article. Since late 1990s, digital certificates have been standardized by X509, a stable and widely implemented supported format. It would be a small jump from there to realize that the SSL protocol universally used for securing communications online has provisions for users to verify their identity with digital certificates and that many large organizations, including the United States Department of Defense have been depending on this capability for years.
This is not to say that there are not good points in the article. OpenID is a major distraction and duplication of effort precisely because it is a mediocre reinvention of the wheel, ignoring all the investments made towards deploying PKI on the web compliments of SSL and muddying the waters one more time just when there was a fighting chance that the industry might converge on a standard (SAML, far from perfect as it may be) as the underlying format for identity assertions. But it is a non-sequitur to argue that OpenID is doomed because of its dependence on passwords and inherent problems with single sign-on.
cemp
BlackHat: making the news while reporting it
Posted: August 9, 2008 Filed under: events, news, risks, Security Leave a comment »DefCon attendees always knew that using the wireless network at the conference is living on the dangerous side– even on the rare occasions a few packets managed to route their way across the congested airwaves with thousands competing for the scarce bandwidth. (This blogger has been depending on his Novatel CDMA modem compliments of Sprint to continue writing.) If there is a real-life incarnation of the proverbial “untrusted network” this is it, and The Wall of Sheep has been the favored tradition for publicly embarassing those using weak protocols that transmit credentials in the clear.
This year the tradition expanded to Blackhat, putting attendees– a much different crowd than DefCon, it goes without saying– on notice that their name could be next on the hall of shame.
Journalists had a better deal: they got their own wired, private network in the press room, free from the shenanigans of creative researchers.
It did not work out. As reported by CNet, French journalists decided to step up to plate and impress their colleagues with their “l33t credentials.” Exact details are unclear but it appears that they managed to take control over the router and capture traffic from other journalists. For anyone not using VPN, that included the stories their they were filing. So much for good sportmanship– why bother attending the conference sessions or interviewing speakers when you can “rephrase” your colleagues’ dispatches instead? The French crew were so proud of their achievements that they wanted to get the spoils displayed on the Wall of Sheep. Conference organizers were not impressed by what they viewed as illegal wiretapping and interception. Neither were fellow members of press, when they were briefed on the incident. The proto-hackers were booted off the conference, which was not enough to appease the irate journalists. The reaction reportedly included at least one person from ZDNet going through the roof.
cemp
From 0wning DNS to 0wning SSL (2/2)
Posted: August 8, 2008 Filed under: Internet, oped, review, risks, Security Leave a comment »But SSL does have an Achilees heel: its trust model is anchored on the digital certificate used by the web server: the only proof that the website you are communicating with Bank of America (as opposed to an impostor in Estonia) is the fact that they have a digital certificate issued by Verisign claiming that this website indeed is www.bankofamerica.com.
The fragility of this model has been pointed out before. Verisign is not the only recognized certification authority; out of the box Windows ships with close to 100 CAs, all of them equivalent for trust purposes. Any one of them incorrectly issuing the Bank of America certificate to somebody else is enough to ruin any guarantees provided by the cryptography– it does no good to secure your traffic, when the person at the end of that encrypted channel is the bad guy. (Perhaps the biggest CA goof was Verisign issuing Microsoft code-signing certificate to impostors in 2001. The implications were much worse than for SSL certificates, but revocation has addressed the fall-out for the most part.) While MITM attacks against SSL due to incompetent CA practices have always been possible, the challenge of playing that messenger in between so far made this a low-likelihood attack vector. Owning DNS changes that.
More importantly– and this is Kaminsky’s main point regarding SSL– the certification process itself uses DNS. According to this version of the story, when the proud new owner of the domain www.acme.net wants a digital certificate, the CA consults DNS records to verify ownership. They might even ask the user to insert some DNS records or add a particular page to the website, as additional proof. All of these checks are trivially subverted if DNS is corrupt because all of them will be routed to servers controlled by the attacker. This means that while the existing Bank Of America certificate is safe and sound, the enterprising criminal will:
- Choose a moderaly incompetent CA
- Subvert DNS to confuse name resolution for that CA
- Pass the domain ownership checks made by the CA
- Obtain a new valid certificate in the name of Bank of America
- Subvert DNS resoution for an ISP
- MITM all of the users at that ISP by using the perfectly valid certificate from step #4
That, at least is the picture painted in the presentation. The critical details are certification steps used– not just by Verisign, Geotrust and other major CAs but every single one of the dozens of certification authorities recognized by IE and Firefox. Extended validation does not help for two reasons: on the usability front, users pay no attention to all the fancy eye-candy browsers waste on displaying EV status, as demonstrated nicely by The emperor’s new security indicators.. On the the implementation level, the browser grants exactly same privilege to regular certificates; embedded content for example can still be subverted using a vanilla cert while keeping the main page over EV.
If this attack does indeed work– and it is impossible to determine without consulting the certification practices for CAs– it shows a circularity in the security model. SSL/TLS are designed to survive exactly the type of mayhem created by DNS hijacking. It does not matter whether traffic is routed to the right website or the wrong one. When the protocol is implemented correctly and the certificate checks out, the user is supposed to be guaranteed that they are dealing with the legitimate website. (That is not much of a guarantee: if the certificate has errors, the protocol will detect it but until recent web browsers used to respond by displaying a cryptic warning that users simply ignored. Even when the certificate is validated correctly, that only proves the identity is what is stated in the URL– which may not be at all the same one that is in the user’s mental picture, to the delight of phishing syndicates everywhere.) Weak certification practices destroy even this glimmer of hope by placing critical faith in DNS to bootstrap a protocol that was purportedly designed to survive complete breakdown of all naming and routing infrastructure.
cemp
From owning DNS to owning SSL (1/2)
Posted: August 8, 2008 Filed under: Internet, oped, risks, Security Leave a comment »Dan Kaminsky walked away with the Pwnie award for most overhyped bug and being a good sport, appeared in person with a brief acceptance speech. The BlackHat presentation did turn into an over-crowded spectacle as expected, there was nothing new to report. (Even though a section of the deck was prefaced with “Here is something that did not leak…”) The cat had been out of the bag, compliments of earlier speculation by Halvar Flake and a miscue by the folks at Matasano. And that’s just the public disclosure: the presentation itself credited several people who identified the same vulnerability within days independently but decided to remain quiet, in keeping with the unusual request.
The more interesting was the second piece of the talk: the question of “why”, why it is worth subverting DNS and what can be accomplished. Decidedly more speculative in nature, in this section Kaminsky argued that SSL, most software updates and online identity management services are vulnerable. If these claims hold for real-world implementation, not simply the marginal ones written by careless developers, it would be more remarkable than the original discovery.
SSL and in general PKI were designed to be resilient against an untrusted network. The design of the protocols assumes the transport is completely unreliable. The metaphor this blogger uses to describe it in security orientation classes is two people, say Alice and Bob, trying to communicate but restricted exchanging post-it notes carried by a shady messenger. In this model it is clear the messenger may fail to deliver the note, and the two sides never manage to communicate. No surprise there. But more interestingly, our shady messenger can erase part of the mesage, add forged languge, for that matter replace the entire note by a new one fabricated out of thin air, change the order in which notes are delivered, even replay one person’s note back to him/her as if it originated from the other side. This bizarre threat model is intended to capture the man-in-the-middle (MITM) attack in the abstract, where a malicious adversary is capable of reading and modifying any message sent between two people.
Communication protocols including SSL/TLS are designed to be secure in this model, in the sense that the nefarious messenger can not read a private message intended for Alice, nor convince Alice that Bob sent a message he did not in fact originate. SSL/TLS protocol itself has lived up to this claim so far– there are no known, practical cryptographic attacks against the protocol itself (as opposed to specific implementations, which can have coding issues that are not intrinsic in the protocol) The closest call was the Bleichenbacher attack against RSA padding first published in 1998 and later refined.
[continued]
cemp
One week to Pwnie Awards
Posted: July 31, 2008 Filed under: Internet, risks, Security, software Leave a comment »Move over Antoinette Perry. There is a new award in town and it will take place at the Black Hat briefings next week in Las Vegas. Pwnie awards will honor (shame?) moments of brilliance and ineptitude in the security research community. Highlights from this year’s crop of nominations include:
- Kernel-mode remote code execution that works on XP, W2K3 and Vista. This after MSFT speculated that the bug would be very difficult to exploit in the real world.
- Adobe Flash null pointer dereference. What appeared to be an innocuous crash that became a cross-platform, cross-browser remote code execution vulnerability after ISS’s Mark Dowd decided to take a closer look. Once again complements of Flash, continuing to undo any improvements in Internet Explorer security by introducing its own mediocre platform on top of an already fragile HTML/Javascript alliance that years of vulnerability research was finally starting to stabilize. All flash, no subtance but millions of users can’t be wrong: the dancing hamsters are clearly worth the risk of getting 0wned.
- QuickTime– no vulnerability required, the nomination committee decided the entire application is one colossal mistake, mired in the 1990s quality control standards (“compiles without errors when most warnings are disabled”) and providing another example of insecure context switching.
- DNS rebinding attacks. Using the web browser to VPN into the internal network behind a firewall. Considering that Kaminsky presented on the topic at last year’s Black Hat, this one has outlived its shelf life.
- Safari carpet bombing. Note to Apple: forcing software on user machines is not a good strategy when you are awfully slow to fix publicly reported vulnerabilities.
- Debian/OpenSSL not-very-random number generator debacle; also nominated for most epic failure.
- Linus Torvalds for controversial views on vulnerability research and handling security bugs.
- Overhyped bugs: DNS poisoning and unauthenticated UPnP control over network devices.
cemp
Fuel pumps and the “Y2K8 crisis”: security feature gone awry
Posted: July 11, 2008 Filed under: risks, Security, transportation 1 Comment »Crude oil at $100/barrel may have been the first psychological barrier for traders. Now long crossed and $150 looming on the horizon, it turns out there is an equivalent one for drivers: the $100 refueling at the friendly local gas station. New York Times reports in the article titled When a tank of gast costs $100 several large trucks and SUVs have enough capacity for hitting the three digits during a refueling stop.
But they often do not quite get there for two reasons. First one is the unwillingness to see the register ringing up that amount. The article cites owners who prefer to refuel long before they are running on fumes, to avoid seeing the full price– and possible wasting more fuel with more frequent visits to the gas station, as well as slightly higher weight of the car on average from carrying more fuel.
The second one is a “security feature:” many pumps that accept credit cards will shut off at $75 to prevent overcharges as well as stolen cards from being used. It seems strange that a criminal in possession of someone else’s credit card would be going on a shopping spree for fuel. Electronics, jewelry and other high value goods that can pawned off appear as more likely candidates. (Never mind the cartoon strips– these measures have been in place since the times when fuel was relatively inexpensive.)
That’s not the worst limitation: in an echo of the Y2K crisis, it turns out that many older pumps are not capable of registering three digits at all. (No word on whether they simply roll back to $0.00 and start counting from there or getting stuck at $99.99.)
cemp
GMail starts enforcing DomainKeys for eBay and PayPal
Posted: July 9, 2008 Filed under: Google, Internet, Security, software Leave a comment »In a sign that Domain Keys Identified Mail deployments have become reliable enough to depend on, Google has started to enforce DKIM signatures on eBay and PayPal.
Quick recap: DKIM is an anti-spam scheme intended to block forged of email messages and verify the sender by using digital signatures. The short version is every large email service provider signs messages originating from their site and the recipients verify them. Strictly speaking this is purely an authentication technology, defined by an open IETF standard– nothing prevents spammers from also signing their message but there is an implicit assumption that somewhere a reputation system will spring into existence to allow vetting the verified identities and blacklisting the miscreants. Microsoft has backed a competing solution called SenderID.
Major challenge with deploying these solutions is dealing with the “gray area.” If a message is properly signed by eBay, it is clearly coming from eBay. (Leaving aside the fact that eBay may have been handing out email accounts to its own sellers and one or more of them are spammers.) That email can be safely accepted. If the message is signed but the signature does not validate, it can be rejected– although even then there are edge cases where innocuous message modifications can cause the signature to invalidate. By design cryptographic signatures are designed to be very brittle; any change to the message invalides them. Domain Keys had to work around this. But what about unsigned messages? It could mean that eBay does not implement the DKIM standard at all. Or perhaps they have not gotten around to deploying DKIM on all the servers. A large service may have hundreds of server dedicated to handling outbound email and the conservative approach is doing a small-scale pilot project first. The final possibility is the message did not originate with eBay and is indeed a forgery, an attempt at phishing for example. It’s important to distinguish these cases because the accept/reject decision for the message will be different.
Strictly enforcing DK would mean that unsigned messages are rejected but that can not be done until there is good reason to believe that the service provider has committed to signing 100% of outbound traffic. In October 2007 eBay (and PayPal, which is owned by eBay) announced plans for adopting DKIM. But until both services could commit to signing all traffic, strict enforcement could mean legitimate messages getting dropped or sent to the junk folder and unhappy users.
cemp