Hi Jon,
On Mon, 4 Oct 2004, Jon Callas wrote:
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.
thank you for taking the time to compose this synopsis, it is very
constructive.
I agree with your assessment that for *end user-to-end user* S/MIME and
PGP signatures would be a poor choice for the MASS application. However, I
am not considering applying S/MIME or PGP to the end user communications.
Instead, I'm suggesting applying S/MIME or PGP to the *server-to-server*
communications. In effect, the first hop MTA server e-mails to the last
hop MTA server the end user's e-mail, both headers and message body, as a
signed e-mail attachment. Conceptually, this can be thought of as
tunneling e-mails through S/MIME based tunnels. The server-to-server
e-mails are authenticated and protected by S/MIME or PGP. In this
architecture, the MUA do not have to change.
Given this perspective, it seems to me that many of things you said below
are not applicable as objections to the use of S/MIME or PGP in this new
"behind the scenes" role between the MTA rather than the MUA. Some of the
issues that you raised will require more examination, see inline below
for my observations and questions...
br,
George
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).
When S/MIME tunneling, the end user's e-mail headers and body become the
protected content. The outer e-mail header used to deliver that payload
refers to the destination tunnel endpoint MTA. The user's original header
is under the signature of the origin MTA and is not subject to mangling
while in transit. We don't care about the outer header being mangled.
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.
So in this scenario, you are relying on the trustworthiness of the origin
MTA to not inject fradulent or spam e-mails into the e-mail delivery
network, but do allow it to send e-mail originating from unauthenticated
virtual users. I understand why you need this capability. Someday, MASS is
gonna have to document this (non-)security model ;o)
* 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.
As explained above, the user's e-mail is signed by the origin MTA. After
decapsulation at the destination MTA, the origin MTA signature is
verified. This is server-to-server authentication, reusing the existing
S/MIME or PGP signature scheme.
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.
Ok. Again, the server-to-server e-mail simply authenticates the origin
MTA, not the end user whose e-mail is in transit as a payload.
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>.
I will take a look later today...
* 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.
In the S/MIME tunneling scheme, the S/MIME and OpenPGP signature schemes
are used "as is" without change. The S/MIME tunnel endpoint processing is
orthagonal.
What is the interesting design problem is wrapping up the end user's
e-mail header and message body into a well-defined syntax, and then
signing that content. The sending MTA then encapsulates the user's e-mail
inside an e-mail addressed to the destination MTA. The destination e-mail
address is a tunnel endpoint that knows how to decapsulate the user's
email and verify the signature of the origin MTA. Both encapsulation and
decapsulation processes reuse S/MIME (or PGP).
<snip text on why MUA changes would not work, agreed, not being proposed>
* 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.
Yes, I have misgivings about this, but given human nature it seems
unescapable. You need not only need to authenticate that the e-mail
originated from "mafia.ru", but also discover that "mafia.ru" has an evil
reputation. How do you that without getting sued by a lawyer for
defamation of character? ;o) But all of that is outside of MASS scope,
thank goodness.
If the spam problem can not be solved until reputation metric systems are
deployed, our grandchildren will still have to deal with spam ;o(
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.
Given that S/MIME and OpenPGP are simply being used as tools that
facilitate a secure tunnel between MTA, the "new system" I am suggesting
is in effect S/MIME security gateways between cooperating MTA systems,
analogous to IPsec security gateways operating in tunnel mode.
Jon