Re: Why we really don't require requirements

[George Gross <gmgross@xxxxxxx>]

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@xxxxxxxxxxxx>. 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
>
>