UCE - a simpler approach using just digital signing?

[Ray Dillinger]

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#token at example.com" where "token" was a field that 
was your own personal password to fred's mailbox.  Your 
system would still send mail to "fred at 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#anything at 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#token at 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#token at 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 majordomo at metzdowd.com