[comp.mail.uucp] Are There Standards For Secure Mail Transfer Via SMTP?

Will@cup.portal.com (Will E Estes) (02/07/91)

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?

Thanks,
Will Estes        (apple!cup.portal.com!Will)

leo@unipalm.uucp (E.J. Leoni-Smith) (02/08/91)

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?

>Thanks,
>Will Estes        (apple!cup.portal.com!Will)

Do you mean secure as in - 'I know the guy got it', or secure as in 
'if someone else got it they need 20 years on a Cray to decrypt it?'

Surely encryption/decryption of data is not a tcp/ip issue?
Or is it.

imp@Solbourne.COM (Warner Losh) (02/09/91)

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".

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).

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.

Or, in other words, you can't trust your mail 100%, since it is
relatively easy 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.

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

rickert@mp.cs.niu.edu (Neil Rickert) (02/09/91)

In article <1991Feb8.180500.11290@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes:
>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).

 Forget about root.  Sure root can violate privacy.  But what does that
matter when anybody with a terminal server can telnet to the SMTP
port of any host, and start entering an SMTP mail transaction.  In this
case even the 'Received:' headers won't be of much help in narrowing down
the source of the message.

 If you want 100 percent secure communication, talk face to face with the
person intended.  Actually, even that is not 100% foolproof, or else there
would be little point in having agencies such as the CIA.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/10/91)

Apologies for the advertisement, but it seems appropriate to point out
that I just posted a public-domain RFC 931 implementation under BSD to
alt.sources, along with patches to sendmail (5.65, 5.61, et al.) that
let you use $F in sendmail.cf for the remote user as per RFC 931. I
recommend that you add ``, auth $F'' to one of the Received: lines,
preferably the second, as a semi-standard format.

Sure, RFC 931 isn't a panacea. But it does turn mail into a secure
protocol, provided that TCP is made secure. Any university sysadmin
knows that 99% of all sendmail forgers don't have any resources other
than a telnet connection. Now we can close that hole for good.

authd 3.01 has been reported to work under SunOS 4.0 on a Sun 2/170,
SunOS 4.0.3 on a Sun 4/280, SunOS 4.1 on Sun 3/80, 3/160, 3/180, 4/60,
and 4/330, Ultrix 4.0 on a DECsystem-5820, Ultrix 4.1 on DECsystem-5820,
DECstation-5400, and VAX 8650, BSD 4.3 on some VAX, and Convex UNIX 8.0
on a Convex C210. It does peek in a few kernel data structures, but it
seems perfectly portable so far.

---Dan