Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP?
Message-ID: <28229:Feb1200:29:5391@kramden.acf.nyu.edu>
Date: 12 Feb 91 00:29:53 GMT
References: <16381:Feb1015:07:5791@kramden.acf.nyu.edu> <9102102022.AA26112@osiris.MIT.EDU>
Organization: IR
Lines: 34

In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes:
  [ RFC 931 ]
> I wouldn't go so far as to say it makes mail a "secure" protocol.

But it does---again, provided that TCP is made secure.

The problem until now is that mail introduced its own security holes
over and above those of TCP: it didn't even try to verify the remote
username. Now at least we can reduce the problem to TCP.

> However for it to be really useful, all the mail relays
> between sender and receiver need to implement it.

I'm not convinced that this is such a problem. The Internet mail I send
rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com.
If sending organization and receiving organization support RFC 931,
that's enough.

> The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself
> here!) define an end-to-end mechanism exactly so that sender and
> recipient need have no trust in the intermediate mail relays (and no
> requirements on the software that they run).

I have no objection to end-to-end security (although I don't like the
current fashion of putting it into every single protocol instead of
making the link level secure). But we don't have the software yet. I
also hope that if NYU decides to spend any money on RSA Inc., it starts
by putting a few thousand dollars into challenging the RSA patent.

Furthermore, mail encryption doesn't do anything for news, telnet,
rlogin, talk, or any of the other services people use. RFC 931 helps all
of them the same way it helps mail.

---Dan