Thank you all for your comments so far, public and private. This
reply addresses all the points I received. If I left anything out from
anyone, please point it out to me.
There seems to be some confusion between signed versus encrypted
email, as well as listserver traffic handling. Please note:
1. I did NOT suggest using signed email (and explained why).
2. I suggested using encrypted email, using the recipient's public-key.
3. I EXCLUDED signed email for the first phase (for reasons well-
known to anyone who is following PKI).
4. If you forge the From address, you won't know how to reach me
-- which is desirable.
5. If you sub to a list and that list's traffic is not encrypted to your
key, you simply add the list's address to your whitelist (btw, I mentioned
this also as a backward-compatibility mechanism in general).
6. Spammers trying to misuse a list as a proxy encryptor (in the
case the list encrypts traffic for each member) could be stopped
before the act in the same ways that lists currently fend off spammers.
In case a spammer does get around the defenses, the additional encryption
burden should be enough motivation for the list's administrator to be
more diligent -- it hurts at home. And, IMO, this is fair because the list
is allowing itself to become a spammer's tool, with or without encryption.
NOTE: the proposal WANTS to penalize spammers. If a list becomes
a spammers' proxy (willingly or not), it is forwarding spam.
7. Large public lists however, such as ietf-org, should probably NOT be
encrypted per member's public-key (because of high list burden, even though
legitimate). Rather, traffic should be signed with the list's private-key,
allowing anyone to verify that the message has satisfied the list's
posting and routing policies before being forwarded. This would
also prevent ghost messages that seem to be from the listserver but
are not.
8. How about spammers using 100,000 slave PCs to share the burden?
Even if a spammer could control 100,000 PCs, the spammer would
need to set up EACH PC with public-key encryption software AND
the public-key for each targeted email address. Anyone working in PKI
knows that this is an extremely hard task for anything more than a
handful of hosts -- even with cooperating hosts.
9. But... what if I'm still worried that #8 is possible just for me? Is
there any recourse using the proposal? Yes -- keep your email address and
change your public-key. An automatic reply saying that your public-key
has changed to value XYZ would be useful to legitimate users and make
life harder for spammers.
10. How about which standard to use? S/MIME, PGP/MIME, etc.?
The ensuing market forces should help, finally, consolidate encryption
standards and promote interoperation. Usage drives standardization and
this is a good thing. Imagine if, as a comparison, we would need to choose
which protocol to use before visiting a web site? Your browser handles it --
HTTP or FTP, for example, it's all transparent to you.
Comments?
Cheers,
Ed Gerck