Re: New version of SMTP/TLS

At 04:41 PM 11/4/97 -0800, Chris Newman wrote:
>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.

Yes, that's clumsy, but it's better that what I have (nothing) and better
that what I came up with before I punted. Do others like this?

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

While I agree that this isn't used often now, I think it will get used a
lot more in the future, particularly for server-to-server authentication. I
think I've made it pretty clear throughout the document that the privacy
and authentication you get is for one hop only; I'd be happy to add it
again, if you point out where.

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

I like your wording, but it doesn't get all of what I had. As a different
replacement, I suggest:

A publicly referenced SMTP server MUST NOT require use of the STARTTLS
extension in order to deliver mail locally. This rule prevents this
extension from damaging the interoperability of the Internet's SMTP
infrastructure. Any SMTP server MAY refuse to accept messages for
relay based on authentication supplied during the TLS negotiation. An SMTP
server that is not publicly referenced MAY refuse to accept any messages for
relay or local delivery 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.

That's no my understanding. I was told that TLS would become SSL v3.1.
Is there a Netscapeoid in the house who can clarify this?

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

I like that, but would like to reword it as:

An SMTP client can protect against this attack by recording the fact that a
particular SMTP server offers TLS during one session and generating an alarm
if it does not appear in the EHLO response for a later session. The lack of
TLS during a session SHOULD NOT result in the bouncing of email, although
it could 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.

Again, I disagree. SMTP/TLS is suitable for authenticated delivery of email.
And, if every hop including the submission hop is authenticated, it is
suitable
for authenticating the author of an email message, even though the draft
should
not be positioned this way. I think the rest of your replacement below is
good:

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


--Paul Hoffman, Director
--Internet Mail Consortium