Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!MIT.EDU!jis
From: jis@MIT.EDU (Jeffrey I. Schiller)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP?
Message-ID: <9102092334.AA17529@osiris.MIT.EDU>
Date: 9 Feb 91 23:34:11 GMT
References: <1991Feb8.180500.11290@Solbourne.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 86


   Date: 8 Feb 91 18:05:00 GMT
   From: stan!imp@uunet.uu.net  (Warner Losh)
   Organization: Solbourne Computer, Inc., Longmont, CO
   References: <38975@cup.portal.com>, <1991Feb8.110317.3949@unipalm.uucp>
   Sender: tcp-ip-relay@nic.ddn.mil

   Will@cup.portal.com (Will E Estes) writes:
   >Can someone briefly discuss any standards that might exist, or be
   >in the process of development, for the sending of secure mail via
   >SMTP or via the Internet.  Also, are there any relevant RFCs on
   >this topic?

   There are a couple of RFC's (1113, 1114, 1115) on something called
   "Privacy enhancment for Internet electronic mail", which is mail that
   has been encrypted.  There are some provisions for authenticating the
   sending user, but they are "weak".

Actually the provisions for authenticating the sending user are quite
strong.  Each sender must have a "Certificate" to send privacy enhanced
mail. A Certificate is a signed (via public key technology) piece of
information that binds the senders name (as an X.500 distinguished name,
separate from any concept of "login" name) and their public key. There
will be at least three ways of obtaining a Certificate. The direct (and
most expensive) way will be to get one issued directly from RSADSI (the
company that is managing the authentication hierarchy) for $25.00. This
method will also require that you submit a notarized statement of your
identity (ie. a Notary Public will have to notarize a piece of paper
that you send to RSADSI, testifying that the notary was shown sufficient
evidence that you are who you claim to be).  The cheaper mechanism (and
more efficient one because no paperwork is required) will involve
someone in your company acting as an "Organizational Notary" (ON). ONs
will vouch for people in the company. However ONs will be under contract
to only issue Certificates legitimately.

   While there is an account called "root" with all the privs that it
   has, there will be no way to have "totally secure, authenticated
   mail".  After all, if I wanted to send mail from Joe Hothead to his
   boss calling him a jerk, then I could su, then su jhothed and flame
   away.  And it could be done w/o a way to trace it back it me (after
   all, root can nuke accounting files).

Not quite as easy as that. To send mail as me, will require knowledge of
my private encryption key (the "secret" key that corresponds to the
public key embedded in my Certificate). In my implementation of Privacy
Enhanced Mail, the secret key is stored not only in a file readable only
to me, but is also encrypted by a password that only I know.

"root" (or others) can still steal my private key, however to do so will
require either stealing my keyboard input when I am sending private
mail, or otherwise installing a trojan horse in the Privacy Enhanced
Mail software to steal my key. Although both of these steps are doable
by one who has sufficient privileges and/or skill, it is a *lot* harder
then merely "su" and then "su jhothed".

   User authentication is a difficult problem to solve completely.  Also,
   while there are sites on the Internet with older mailers (and can't be
   upgraded to the latest sendmail since they aren't running Unix), there
   will be a problem with mailer spoofing.  Even with the latest
   sendmail, I could send mail to Joe's boss as Joe w/o any privs.

Privacy Enhanced Mail is not a function of the mail transport system, it
is a step you take prior to sending mail or after having received the
mail. My implementation is in fact done as an editing step. First you
format your message in an editor, then you transform it to the
"enhanced" form and only then do you mail the message. In fact I have a
version which is implemented as a UNIX filter. You can pipe the
unenhanced message in, and get the enhanced message out.

   Or, in other words, you can't trust your mail 100%, since it is
   relatively easy to forge.

The goal of privacy enhanced mail is to allow you to trust your mail
closer to 100% then to 0%. The whole point is to make it hard to forge.

   However, I encourage all reasonable steps that can be taken to
   authenticate a connection.  There are many hueristics that can be used
   to detect clumsy forgeries.

The problem with using heuristics is that they often will flag a
legitimate message as a forgery! My strategy is to not trust any
information provided by the IP layer, as all of it can be forged. The
mechanisms in Privacy Enhanced Mail are designed to be trusted, and were
designed by people who know their business.

			-Jeff