Securing Internet mail at the MTA level

Hi,

Recently, I've been looking into securing email at the MTA level, and
would like to get your thoughts on implementation possibilities and
related issues.

The problems that I'm trying to solve are:
    1. Host authentication
    2. Data privacy

In order for the widespread encryption to work, several things need to
occur:
    1. Phase-in of the new stuff
    2. Backward compatibility (ability to continue to work in the
       clear) for a period of years
    3. A single worldwide mechanism, defined by an RFC, and freely
       available, except, perhaps, in the case of commercial
       MTAs. (i.e., the use of RSA seems appropriate for host and
       session key management, and is free via RSAREF in the US, free
       outside of the US, but not free for commercial use. This seems
       acceptable to me.)

Two types of approaches are possible:
    1. Adding to the SMTP protocol itself, allowing for MTAs to
       identify crypto-capable peers, and then performing
       authentication and session encryption where possible.
    2. Waiting for a cryptographic transport layer network protocol
       (such as what is being proposed in draft-ietf-tls-ssh-00),
       allowing SMTP to remain untouched, and only requiring MTAs to
       add support for the new network protocol.

I like the second approach better, because it allows more problems to
be solved with one move, and it would be easier to add crypto
functionality to our common network utilities by simply making them
aware of the new transport layer protocol. The first approach would
require redefinitions of RFCs for each of the services, and lots of
redundant work.

I mentioned my interest in an SSH-capable MTA to Tatu Ylonen
<ylo@ssh.fi>, and he as also expressed interest. The word from him on
the status of the SSH Internet Draft is that a reference
implementation should be available early next month. I'm considering
using that reference implementation to add SSH capability to an MTA,
perhaps sendmail.

My questions are:
    1. Which of the two approaches seems to make the most sense to
       you?
    2. Is there another approach that could work better?
    3. Is there interest in adding SSH functionality to sendmail in
       the near future (either by the draft spec, or once the RFC has
       been published)?

Please feel free to pass this around, if you deem appropriate. I'm
interested in lots of feedback before deciding if and how to go ahead
with the project.

Thanks.

-- 
C Matthew Curtin        MEGASOFT, LLC        Director, Security Architecture
I speak only for myself.  Don't whine to anyone but me about anything I say.
Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet
cmcurtin@research.megasoft.com http://research.megasoft.com/people/cmcurtin/

On Tue, 20 Aug 1996, C Matthew Curtin wrote:

> Recently, I've been looking into securing email at the MTA level, and

> Two types of approaches are possible:
>     1. Adding to the SMTP protocol itself, allowing for MTAs to
>        identify crypto-capable peers, and then performing
>        authentication and session encryption where possible.
>     2. Waiting for a cryptographic transport layer network protocol
>        (such as what is being proposed in draft-ietf-tls-ssh-00),
>        allowing SMTP to remain untouched, and only requiring MTAs to
>        add support for the new network protocol.
> 
> I like the second approach better, because it allows more problems to
> be solved with one move, and it would be easier to add crypto

> I mentioned my interest in an SSH-capable MTA to Tatu Ylonen

> My questions are:
>     1. Which of the two approaches seems to make the most sense to
>        you?

I think something like the first one would be a little bit better. In my
mind I see something similar to the "ESMTP" message appearing on
connection to the mail daemon - "SSLESMTP" if you will. Then client could
issue a "ENCD SSL" command (or whatever) and it would go crypto. I already
have used telnet and FTP clients that does something similar to this, and
they work almost transparently....

>     2. Is there another approach that could work better?
>     3. Is there interest in adding SSH functionality to sendmail in
>        the near future (either by the draft spec, or once the RFC has
>        been published)?

Have you looked at SSL? It allows different algorithms to be used, etc.
etc. (although the certificate & key distribution method uses x509, which
may be a pain...?). The SSLeay library is a freely available
implementation of SSLv2.

Just MHO,

 --==== Elliot Lee = <sopwith@redhat.com> == Red Hat Software ====--
"Usenet is like a herd of performing elephants with diarrhea; massive,
 difficult to redirect, awe-inspiring, entertaining, and a source of
 mind-boggling amounts of excrement when you least expect it."

Elliot Lee wrote:
| On Tue, 20 Aug 1996, C Matthew Curtin wrote:

| > Two types of approaches are possible:
| >     1. Adding to the SMTP protocol itself, allowing for MTAs to
| >        identify crypto-capable peers, and then performing
| >        authentication and session encryption where possible.

like pgpsendmail?

| >     2. Waiting for a cryptographic transport layer network protocol
| >        (such as what is being proposed in draft-ietf-tls-ssh-00),
| >        allowing SMTP to remain untouched, and only requiring MTAs to
| >        add support for the new network protocol.

| >     2. Is there another approach that could work better?
| >     3. Is there interest in adding SSH functionality to sendmail in
| >        the near future (either by the draft spec, or once the RFC has
| >        been published)?
| 
| Have you looked at SSL? It allows different algorithms to be used, etc.
| etc. (although the certificate & key distribution method uses x509, which
| may be a pain...?). The SSLeay library is a freely available
| implementation of SSLv2.

	The big problem with adding SSL or ssh to mail transport is
that both assume that mail goes from host A to host B, with none in
between.  This is useful, but its more useful (IMHO) to integrate something
that doesn't use online key exchange to ensure end to end security.

	Take for example, Alice sends mail to Dave via Brian and
Charlie.  A point to point protocol, while useful against Eve and
Mallet, doesn't address the fact that Brian works for the NSA.  While
if Alice's sendmail encrypts the message to Dave, then Brian and
Charlie are reduced to traffic analysis instead of reading the mail.

	The case of mail being carried by an intermediary is still
pretty large.

	In any event, I don't see an advantage other than buzzwords to
using SSL/SSH over PGP, while I do see advantages to pgp.

Adam



-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

At 8:29 AM -0700 8/20/96, C Matthew Curtin wrote:
>    2. Waiting for a cryptographic transport layer network protocol
>       (such as what is being proposed in draft-ietf-tls-ssh-00),
>       allowing SMTP to remain untouched, and only requiring MTAs to
>       add support for the new network protocol.
>
>I like the second approach better, because it allows more problems to
>be solved with one move, and it would be easier to add crypto

	This presumes that everyone uses Internet protocols for transport.

	That is a marginal assumption, in today's world.

	Probably ok for long term, though.

d/

--------------------
Dave Crocker                                            +1 408 246 8253
Brandenburg Consulting                             fax: +1 408 249 6205
675 Spruce Dr.                                 dcrocker@brandenburg.com
Sunnyvale CA 94086 USA                       http://www.brandenburg.com

Internet Mail Consortium               http://www.imc.org, info@imc.org