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

From: Rik Drummond <[email-masked]>
Date: Tue, 4 Nov 1997 19:13:10 -0600

I agree with Keith. This is a good idea... even if Paul thought of it :-) :-) :-).... Rik

-----Original Message-----
From:	Keith Moore [SMTP:[email-masked]]
Sent:	Tuesday, November 04, 1997 3:45 PM
To:	Ran Atkinson
Cc:	[email-masked]; [email-masked]
Subject:	Re: I-D ACTION:draft-hoffman-smtp-ssl-04.txt 

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

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: Chris Rapier <[email-masked]>
Date: Tue, 4 Nov 1997 23:01:11 -0500 (EST)

I happen to think that there is a lot of leeway within the SMTP
architecture that we aren't taking advantage of. 
For example...

Can we assume that most SMTP handlers will respond with an error on an
unknown command and then continue? If we can assumee that then we have a
reasonable way of determining if an MTA can support additional hooks.
Between compatible MTAs one of thse hooks could be establishment of a
secure connection prior to the passage of envelope information. If the
recipient doesn't support SSL or TSL or whatever, the sender will
fallback to cleartext.

chris rapier

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 Nov 1997 21:14:15 -0800 (PST)

> recipient doesn't support SSL or TSL or whatever, the sender will

Such assumptions are unnecessary. The standard SMTP protocol now supports an
EHLO command. (See RFC 1869 for details, and note that this is now a full
Internet Standard.) This command list the extensions which are available. If a
given extension like, say, TLS, is listed as available, one can assume that the
commands associated with TLS are also available.

Paul's SSL draft already uses this facility to advantage.

				Ned