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/
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
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
participants (4)
-
Adam Shostack -
C Matthew Curtin -
Dave Crocker -
Elliot Lee