Subject: I-D ACTION:draft-hoffman-smtp-ssl-04.txt

From: [email-masked]
Date: Tue, 04 Nov 1997 09:42:46 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SMTP Service Extension for Secure SMTP over TLS
	Author(s)	: P. Hoffman
	Filename	: draft-hoffman-smtp-ssl-04.txt
	Pages		: 4
	Date		: 03-Nov-97
	
This document describes an extension to the SMTP service that allows
an SMTP server and client to use transport-layer security to provide
private, authenticated communication over the Internet. This gives
SMTP agents the ability to protect some or all of their communications
from eavesdroppers and attackers.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-hoffman-smtp-ssl-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-smtp-ssl-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-hoffman-smtp-ssl-04.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked] (Ran Atkinson)
Date: Tue, 4 Nov 1997 11:35:04 -0800

I'd like to suggest that the above draft is causing a problem
rather than solving a problem.

The right approach to email security is within the application
(PGP or whatever).  Trying to add SSL to SMTP islikely to
break interoperability of mail systems and cause operational
grief.  In no event is adding SSL to SMTP solving any sort
of technical problem.

Now perhaps its solving some marketing problem, but then it would
belong in the IMTF rather than the IETF.

All IMHO.

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Nov 1997 16:45:09 -0500

> grief.  In no event is adding SSL to SMTP solving any sort

I disagree.

TLS could be used within enclaves (intranets, if you prefer) to
provide privacy on a per-hop basis.  Even if that solution doesn't
scale to the whole Internet, it would still provides a useful degree
of protection for local traffic against local attackers.  And it does
so without having to authenticate individual users so it's much easier
to deploy than "PGP or whatever".  No, it doesn't provide end-to-end
security for the whole Internet, but neither does it claim to do so.

TLS could also be used to authenticate mail clients and servers to
thwart unauthorized submission and relaying -- which are a huge
problem with present-day SMTP.  "PGP or whatever" doesn't solve this
problem at all.

There's a large demand for this functionality, from people who need
it.  We need a standard way to do this so that mail clients and
will interoperate with mail servers, and servers will interoperate
with each other.

Keith

---

From: [email-masked]
Date: Tue, 04 Nov 1997 17:07:57 -0500

> grief.  In no event is adding SSL to SMTP solving any sort

Umm.. Is this the author of RFC1827 saying this?

Remember that there is a LARGE class of mail hubs (Unix running Sendmail)
that can upgrade their MTA a lot easier than their TCP/IP stack....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 04 Nov 1997 17:22:22 -0800

At 11:35 AM 11/4/97 -0800, Ran Atkinson wrote:
>In no event is adding SSL to SMTP solving any sort
>of technical problem.

In addition to the problems Keith listed that SMTP/TLS solves, there is
another big one: privacy of the SMTP commands. The MAIL FROM and RCTP TO
commands have very valuable information that can be trivially snooped;
SMTP/TLS solves this. (IPsec solves it better, of course, but it isn't
there yet and all the parts needed for SMTP/TLS are). PGP/MIME and S/MIME
do not solve the SMTP command snooping problem.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 Nov 1997 19:55:31 -0800 (PST)

> ...

> will interoperate with mail servers, and servers will interoperate

I agree with Keith and Paul about this. It is certainly true that
end-to-end message security solves a lot of security problems for email,
but it does not solve all of them. And while it may also be true that
alternatives to TLS/SSL exist, none of them enjoy anything remotely
resembling the deployment of TLS/SSL. As such, it would be silly not
to provide this option.

There's also the fact that this approach is going to be used whether we
like it or not. And there are right ways to do it -- ways that interoperate
well with existing SMTP infrastructure -- and wrong ways -- ways that
don't interoperate well or, when they do interoperate, result in security
exposures. Significant value attaches to this proposal for this reason
alone.

				Ned

---

From: Chris Newman <[email-masked]>
Date: Tue, 04 Nov 1997 17:13:04 -0800 (PST)

> belong in the IMTF rather than the IETF.

I'm not particularly fond of the proposal myself, but I believe
standardizing it will be a net benefit to the Internet.  I do see value in 
hop-to-hop privacy for cooperating hosts or sites and this is much easier
to deploy at a site than "PGP or whatever."  Especially since the only
standards track object security protocol with any significant deployment
(PGP/MIME) is undergoing an incompatible revision.

Personally, I find TLS to be vastly more complicated than necessary (all
that X.509 and ASN.1 junk).  I wish it were as simple and well engineered
as draft-ietf-secsh-transport-02 (which is about 1/3 the size of the TLS
specification, provides more functionality and is much clearer), but I
doubt the big software vendors would be willing to make such a radical
change from SSL at this late date.  Another QWERTY/Dvorak situation, I
suppose.

The other important reason to standardize this proposal is that it
negotiates the security within the EHLO framework so it is backwards
compatible with the existing SMTP infrastructure.  I've heard rumors of
people wanting to use SMTP on a different port for SSL/TLS which would
profoundly degrade the reliability and performance of the Internet SMTP
infrastructure.  Someone even registered a port for this purpose.

		- Chris

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Nov 1997 20:55:02 +0100

In your previous mail you wrote:

=> I agree! If one wants to secure person to person messaging
then something like PGP is needed, if one wants to secure the
infrastructure itself (often both are needed) then IPSEC should
be used, and not only for SMTP... In fact I can see only one
argument for SMTP over SSL, it is the unavailability of IPSEC
in many current systems but (I expect) it is a short term
problem then a BCP (best *current* practice) document should
be (more than) enough.

Regards

[email-masked]