Re: New version of SMTP/TLS

On Tue, 4 Nov 1997, Paul Hoffman / IMC wrote:
> There is a new version of the SMTP/TLS draft available at
> <http://www.imc.org/draft-hoffman-smtp-ssl>. I think this covers all
> previous comments.
> 
> If we're all happy with the draft, I'd like to send it in for IETF last
> call next week. Please speak up if you have any issues with this.

Some comments on the draft:

You need to define what a publicly referenced SMTP server is, something
like:

A publicly referenced SMTP server is an SMTP server which runs on port
25 of an Internet host listed in the MX record (or A record if an MX
record is not present) for the domain name on the right hand side of an
Internet email address.

Can anyone else do better?  I recognize this is slightly circular due to
the definition of an Internet email address.

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

I'd prefer that the word "authenticated" be struck from this paragraph as
I believe it is misleading.  SSL/TLS is rarely used for client
authentication and this extension can't be used for authenticated delivery
of email or authenticated authorship -- it can only authenticate one hop.

> Further, there is often a desire for two SMTP agents to be able to
> authenticate each others' identities. For example, a secure SMTP
> server might only allow communications from other SMTP agents it
> knows, or it might act differently for messages received from an agent
> it knows than from one it doesn't know.

This needs to be worded much more carefully.  Here's an attempt:

A publicly referenced SMTP server MUST NOT require use of the STARTTLS
extension in order to deliver email locally.  This rule prevents this
extension from damaging the interoperability of the Internet's SMTP
infrastructure.  However, an SMTP server MAY refuse to accept messages for
relay based on authentication supplied during the TLS negotiation.

> TLS [TLS], more commonly known as SSL, is a popular mechanism for
> enhancing TCP communications with privacy and authentication. TLS is
> in wide use with the HTTP protocol, and is also being used for adding
> security to many other common protocols that run over TCP.

This is false.  TLS is not used at all with the HTTP protocol.  TLS is not
SSL.  You might instead say that TLS is a newer standards-track version
of the non-standard SSL protocol.

>A man-in-the-middle attack can be launched by deleting the "250 TLS"
>response from the server. This would cause the client not to try
>to start a TLS session.

I suggest adding:

A client can protect against this attack by recording the fact that a
particular server offers TLS and generating an alarm if it does not appear
in the EHLO response for a session.  This SHOULD NOT result in the
bouncing of email, although it MAY result in delayed processing.
 
>Another draft, [SMTP-AUTH], proposes a different mechanism that can
>also add privacy and security to SMTP. [SMTP-AUTH] does not allow for
>using TLS, but instead describes how to enable other security protocols
>when using SMTP.

I suggest instead:

This extension is not suitable for authenticated delivery of email, nor is
it suitable for authenticating the author of an email message.  Another
proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
security multiparts [MIME-SEC] can be used to authenticate the author of
an email message.  In addition, the [SMTP-AUTH] proposal offers simpler
and more flexible options to authenticate an SMTP client and the
SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the
STARTTLS command to provide an authorization identity.

		- Chris