It is very possible that email as we know it may be re-invented because of
spam. It may not be "email" or such, but an open message medium. For
instance the number of people that took up Napster, Kazza and Gnutella is
huge. People are capable of adopting new technologies if there are enough
advantages for them (free music) in this case. So I am merely arguing that
if it is decided that we need a new system, it may be taken up by the users.
Part 1: Requests & description
One of the factors other than free music that made P2P so adopted was that
it needed no infrastructure aside from what it made itself. It should then
be noted that this is a key factor for any replacement system.
While we're re-inventing the wheel, it'd be nice to be able to have more
control over email in general. I can send a message to Mike, but once it's
in his hands, it's his to control. This is both good and bad, depending on
the nature of the email and the social situation.
Suppose I send confidential information to Carrie. Once in Carrie's hands,
she can forward it to this mail list. I am powerless. I can send a note that
says not to do it, but there's no way for me to prevent her from doing that.
Now maybe Mike wants to forward a message that I sent to him. I am a rather
private person, and I don't want my email address revealed to the people he
forwards it to. Or maybe some are ok, others are not. I want control of
that.
I also want between here and there transparently encrypted. All email is
confidential, unless it is specifically made public. Currently the situation
is the reverse.
One such way is, in a breath, a P2P receiver-retrieve solution. I imagine me
being able to deposit a file on a server, SSL between me and the server. The
file is encrypted for the receiver. Receiver's P2P agent finds the file*,
downloads the file and the agent does the decryption.
This sounds sort-of like a receiver-retrieve proposal that I balked at a
while back, but the difference is that other P2P servers can request the
file. There can be caching servers who use a variety of caching policies.
For instance, a server may cache entries for people who's address begin with
'A'-M', others may cache those with .edu domains, etc. Essentially, the
receiver is a caching server for his exact address only. Note that domain
email servers will likely only cache for their domains.
Part 2: How this effects spam
Believe it or not, the spammer cannot tell that you picked up your mail. The
caching servers blindly cache messages. An access of the file doesn't mean
that your email is valid.
The spammer (Sam) needs to know your pub-key. The user agent generates and
handles key issues transparently. You get the key by sending an unencrypted
key request to the user (Alice) on the P2P network that contains the
sender's (Bob)agent info. (This request may be propagated on the network
too) The both Bob's and Alice's pub-keys are encrypted over SSL to prevent
spammers from collecting either person's public keys. Note that Sam may
intercept the plain-text key request on his caching server, and get the
agent info for Bob but if Sam masq's as Alice, then he'll notice because Bob
will only fill the request for keys once for Alice.
To prevent a replay attack, the agent must track the files he creates, and
only respond to open ones.
Part 3: Buttoning it up
I still have not fixed the problem of controlling who-gets-what mails. Alice
can still forward her en-encrypted copy. This is unfortunate, and we can
never find away around it, unless you can tag the individual bytes of a
message. But what we can do, is rather than forward our copy, we can forward
a reference to the original (and save some bandwidth too) When this is
performed, Alice must send the public keys (over SSL again) to Bob's agent**
and request that he make copies for those people whose keys are presented.
Bob can simply deny or accept the request by not performing or performing
the encryption respectively.
Bob can then track a message and it's propagation.
If Bob is a spammer, this is bad. But I know of no one who forwards spam
messages. Still a spammer can collect by operating a list that gets
forwarded a lot, which bring me to **. ** Alice doesn't actually send the
keys, just tells Bob's agent which ones to request. The individual agents
can then honor Bob's request or not through simple policies: Accept all,
Manual+Previous State***, or Manual. I prefer manual.
***While annoying, the Alice can revoke her keys at any time. Her agent
seeing failed decryption of messages will attempt to update Bob's version of
her pub-keys, provided that he was previously accepted. This can be done
transparently, and should only cause annoyances for people set to Manual.
The effect on spammers is catastrophic. They may get Alice's keys, but not
for long.
I'm sure I forgot something, but I think I nailed everything I wanted to...
Comments?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg