I have a disgustingly simple proposal. It seems to me that one of the primary reasons why UCE-limiting systems fail is the astonishing complexity of having a trust infrastructure maintained by trusted third parties or shared by more than one user. Indeed, "trusted third party" and "trust shared by multiple users" may be oxymorons here. Trust, by nature, is not really knowable by any third party, not the same for any set of more than one user, and in fact the people most willing to pay for it at least where UCE is concerned, experience shows to be usually the _least_ trustworthy parties.
So why hasn't anybody tried direct implementation of user- managed digital signatures yet? A key list maintained by individual recipients for themselves alone could be astonishingly simpler in practice, probably to the point of actually being practical. In fact, it is _necessary_ to eliminate third parties and shared infrastructure almost entirely in order to allow mail recipients to have the kind of fine-grained control that they actually need to address the problem by creating social and business feedback loops that promote good security. As matters stand today, there is no protection from UCE. If I know there is a user account named 'fred' on the host 'example.com', then I have an email address and I can send all the UCE I want. And poor fred has the same email address he gives everybody, so he gets spam from people who've gotten his address and he has no idea where they got it. All his legitimate correspondents are using the same email address, so he can't abandon it without abandoning *all* of them, and he doesn't know which of them gave his address to the spammers. What if email accounts weren't that simple? Consider the implications of a third field, or "trust token," which works like a "password" to fred's mail box. Your mailer's copy of fred's email address would look like "fred#to...@example.com" where "token" was a field that was your own personal password to fred's mailbox. Your system would still send mail to "f...@example.com" but it would include a "Trust:" header based on the token. The simplest solution I can think of would be a direct application of digital signatures; the trust token would be (used as) a cryptographic key, and the headers of any message would have to include a "Trust" field containing a digital signature (a keyed cryptographic hash of the message, generated by that key). Messages to multiple recipients would need to contain one "Trust" field per recipient. Its use would follow simple rules: Each time Fred gives out his email address to a new sender, he creates a trust token for that sender. They must use it when they send him mail. So fred gives his bank a key when he gives them his email address. If fred were willing to recieve mail from strangers, he could publish a trust token on his webpage or on usenet or whatever - it would be painless to revoke it later, so why not? If fred trusted someone to give out his email address, he could give that person multiple trust tokens to pass along to others. Again, an error in judgement would be painless to revoke later. Fred can revoke any trust token from his system at any time, and does so whenever he gets spam with a trust token he issued. In UI terms there'd be a button in his mail reader that works as, "this message is spam, so revoke this trust token because now a spammer has it." Other messages sent with the same trust token would disappear from his mailbox instantly. Fred might not push this button every time, but at least he'd know what spam he was getting due to (say) his published trust token on his webpage or usenet, and what spam he was getting due to his relationship with a bank, and he'd have the option of turning any source of spam off instantly. In the short run the .aliases file on the mail host would need a line so it would know to deliver mail to "fred#anyth...@example.com" to fred. This is not because a legitimate email would ever include the literal key, but for purposes of alerting fred's MUA to protocol breaches, so it could do key management. Fred's MUA could then be upgraded to use tokens without affecting other users on the system. In later MDA's that handle trust tokens directly, this forwarding would be automatic. Whenever Fred gets email sent by someone using a trust token, his system tells him which token - ie, what sender he gave that trust token to. So email sent to fred using the trust token he gave his bank will show up in his mailbox under a heading that says "this was sent by someone using the trust token you gave your bank." Whenever fred gets email for "fred#to...@example.com" and that's still a legitimate token, his system revokes the token, sends him an automatic note that says which trust token was revoked, and bounces the email with a message that says, "Your mailer is not using trust tokens. Your mail has not been delivered and the trust token you used has been automatically revoked because your mailer sent it in cleartext instead of using it correctly. Please update your mailer and contact fred via some other channel to obtain a new trust token." Whenever fred gets email for "fred#to...@example.com" and it's not a legitimate token anymore, it bounces with the same message, but doesn't generate another note to fred. Fred can see the status of all his tokens (live or revoked) when he looks at his address book. Whenever Fred gets email with no trust token, his system bounces it with a message that says "Contact fred using some other means to get a trust token for email." Whenever Fred gets email with a revoked trust token, his system bounces it with a message that says, "Sorry, this token is known to have been compromised; if you're a legitimate sender then either you've sent mail using a mailer that doesn't handle trust tokens correctly or somehow a spammer has read your email database. If you are a legitimate sender and you've updated your mailer, repaired your data security, or stopped selling your mailing list to spammers, whichever is applicable to your situation, then please contact fred using some other means to get a new trust token." If fred gets UCE under his bank's trust token, then he can revoke that token, and have a few words with the bank about their information security and how some spammer was able to get his hands on that trust token. This would promote early detection of breaches of information security and suborned machines, and also rapid detection of institutions that sell email information to spammers in violation of the users' trust. The bank would have a motive it now lacks to keep spammers out of its email database; every address/token combination used to send spam would instantly stop working, requiring them to resort to (relatively) expensive paper mail or use the phone in order to contact their legit customer. And if it happens again, and again, and again, then fred is likely to do his banking elsewhere in the future. To me, this feedback is the invaluable missing link that all the third-party trust and shared-trust schemes I've seen lack. When fred maintains his own trust keyring, both fred and the bank know where the spammer got the trust token. Also, both of them know the other will know where the spammer got the trust token. A spammer getting the trust token fred gave the bank will cost the bank money, customer goodwill, and potentially business. And fred and the bank must have contact with each other about it if there is still a mutual wish to reestablish email communication. Machines suborned by spammers would be detected instantly because all the trust tokens would be revoked within minutes of the spammer using them. Spammers could not share trust tokens around to get thousands of spam delivered on each one, because fred would revoke the token the first time he got spam on it and all the other spam would disappear. This would destroy spammers' motive to cooperate by selling each other spamlists. And when fred did revoke a key, none of his legitimate email still arriving under non-compromised tokens would be affected. Literally *EVERY* piece of spam would be evidence of an information security breach traceable to a single entity that fred gave his address to, and every time spam were recieved there would be a single action that fred could take to stop getting spam derived from that particular information security breach. This is basic digital signatures; it would work. We know how to do it. We've known how to do it for a long time. People would need to add one field to their email information to keep trust tokens. Everything else you could implement in the Mail User Agents. My inner cynic says nobody's implemented it because nobody can figure a way to make money by selling trust when users manage their own keyrings rather than paying a third party to manage keyrings for them. Can anybody else think of a better reason, or are we really just lazy greedy bums who can't be bothered to work on something unless we can "make money fast" doing it? Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com