-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I too have yet to hear a cogent explaination why S/MIME with
appropriate
header information included under the signature would not handle this
problem. If I'm beating a dead horse, plz let me know where this
thrashing has been archived (I acknowledge that I'm new to this list).
Allow me to try to give one.
Let me say up front that I am a provider of both OpenPGP and S/MIME
systems. I have a commitment to support in my systems whatever MASS
produces as well as whatever MARID finally ends up with (or failing
that, SPF).
None of the RFC 1847-based systems (both S/MIME and OpenPGP/MIME build
on 1847) are sufficient for these purposes. Here's why:
* They solve different problems. 1847 is a content-security system. It
is specifically not designed to handle header security, and if anything
header security is an anti-goal. Protecting subjects, from lines,
dates, and so on are things that 1847+ simply does not address. While
MASS must handle the security of some of the content (to compensate for
replay attacks), it is primarily dealing with the security of the
headers and can apply a less-strict security policy to the body (and in
fact must, because there are many parts of the body that do get
modified and MASS must compensate for this). Lastly, 1847 doesn't work
for fake users. MASS must. For example, MASS has to work for the case
of <do-not-reply(_at_)merchant(_dot_)com>. In fact, it is *more* important that it
work for virtual addresses like this than for "real" users.
* The security models are different. S/MIME and OpenPGP are designed
for user-to-user security. The problem MASS is solving is a different
problem, that of server authentication. For example, Yahoo wants to
know if a message really came from eBay. It doesn't care any more than
that. That is all it needs to know. Furthermore, one of the anti-goals
of MASS is for it to be a privacy-violating system. For example, both
Domain Keys and Identified Mail are very carefully construct to be as
privacy-friendly as possible. If MASS gets a rep for being
privacy-unfriendly, it's going to fail.
Also, it is vital for the system to work at all that is be a
server-authentication system. I wrote an article on how an organized
gang of spammers can launch an attack of an end-user authentication
system and bring about its collapse. Take a look at:
<http://www.pgp.com/resources/ctocorner/cryptoandspam.html>.
* We need simplicity. As someone who's got to implement all this, let
me tell you that OpenPGP and S/MIME are hard enough to do as it is
without complexifying them further. I would rather implement four
(relatively) simple protocols than two more complex ones. Shoehorning
MASS into S/MIME makes as much sense as advocating getting rid of SMTP
and putting it all in IMAP.
* It requires MUA changes. If you add in a new MIME part, it requires
not only changes in every MTA, but in every MUA, too. Furthermore,
MIME-handling is one of those things that the existing MUAs don't do
very well at all. This is the dirty secret of MIME. MIME works
flawlessly when it is a form of file transfer. If I "email you a
document" -- that's what MIME does best. It works nearly perfectly when
you use it as transport for rich text email (think of an HTML body and
a few pictures riding along). It works mostly kinda okay with security
multiparts. I don't know of a single MUA that can handle a message with
rich text, pictures, attached files, and some combination of signing
and encrypting.
Adding in a new dialect of security multiparts is going to require that
every MUA, from Outlook to Notes to Eudora to Mutt to Hushmail to Gmail
to handle this. It isn't going to happen on the schedule it needs to.
Even if you wave a magic wand have everything supporting it tomorrow,
there will be user pushback. They won't want to install it without
testing, they won't want to pay for the upgrades, and on and on.
One of the advantages that header-based systems like Domain Keys and
Identified Mail have is that MUAs are *really* good at hiding the users
from scary headers. It thus has very good backwards compatibility
features.
It is my opinion that any system that requires an MUA change will fail.
It's as simple as that. I can tell you that *I'm* not going to change
my MUA. Furthermore, when a large ISP starts getting support calls
about "these funny attachments" they're more likely to turn it off than
continue to use it. Email is such a critical part of the infrastructure
that requiring a flag day on it will doom an otherwise good system.
* MASS (along with all other authentication systems including but not
limited to MARID) is necessary but not sufficient. It needs some
semantic processing, too. You have to know that when the domain
'mafia.ru' sends you an email, that you have to know whether or not you
are going to be accepting mail from that domain at all. This is a
subtle and very important point because it adds to friction on any of
the above points. It means that the objections people have to any sort
of inconvenience will be magnified by this fact. They will
over-simplify this fact with the phrase, "...and it doesn't actually
work." If, for example, MASS requires someone to upgrade their MUA,
people will say, "This is an excuse to pry money out of you for a
spam-fighting system that doesn't actually stop spam." You'll see
newspaper articles that say, "What are those funny attachments? They're
part of a new Internet spam-fighting system that clutters your mailbox,
but doesn't actually stop spam."
This is why S/MIME and OpenPGP aren't going to work. This is why we
need a new system.
Jon
- --
Jon Callas
CTO, CSO
PGP Corporation Tel: +1 (650) 319-9016
3460 West Bayshore Fax: +1 (650) 319-9001
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 1.2.2
iQA/AwUBQWG6mFK/Wka8mOY9EQJYSACdGqsn9iQfpv76rKgbt7h/b9YJxP0AoL/M
EwgJgosq8nxjcwrfNQSVfrlR
=RIke
-----END PGP SIGNATURE-----