Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

Well, I was hoping that someone else would chime in, but that doesn't 
seem to be happening. Other comments are welcome.

At 12:51 AM -0400 7/1/01, Keith Moore wrote:
>here are some comments on this document
>
>1. section 5 says:
>
>     A publicly-referenced SMTP server MUST NOT require use of the
>     STARTTLS extension in order to deliver mail locally. This rule
>     prevents the STARTTLS extension from damaging the interoperability of
>     the Internet's SMTP infrastructure. 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 mail address.
>
>this might seem like a nit, but the fact that a host is listed as an MX
>for a particular domain does not compel that host to run an SMTP server
>that accepts mail for that domain - because nothing ensures that the party
>that administers the DNS zone containing the MX record  has the
>authorization of the party running the SMTP server to list that server
>as a mail exchanger for that domain.
>
>(lately, several people report seeing lots of SMTP errors of the form
>"we're not a mail exchanger for this domain".  whether this is more
>likely due to a misconfiguration of the SMTP server, or of the DNS zone,
>is unclear.)
>
>so I might suggest a slight change in wording
>
>     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 mail address, and
>     when the SMTP server is configured to act as a mail exchanger for that
>     domain.

That seems fine to me.

>but more generally, it seems like what needs to happen in response to
>the RCPT command, when an SMTP server wishes to refuse non-TLSed mail,
>is this:
>
>server listed  |	SMTP server configured to act as mail exchanger
>as an MX for   |	for recipient domain
>the recipient  |
>domain         |                  no            |           yes
>--------------------------------------------------------------------------
>       no        | 530 must use starttls          | 530 must use starttls
>                 |   or                           |
>                 | 5xx not configured as an MX    |
>                 |   for domain x.y               |
>--------------------------------------------------------------------------
>      yes        | 5xx server incorrectly listed  | return 2xx, 4xx, or 5xx
>                 |  in DNS as MX for domain x.y   | based on whether the
>                 |  (or similar message)          | recipient address is valid

Do others agree with this chart? I'm not that comfortable with 
describing what a server that is not listed as an MX for a domain but 
is configured to accept mail for that domain should do. Also, how 
would a server that is not configured to accept mail for a domain 
know whether or not it is listed as an MX for that domain? This is 
not the document to describe those situations. I'm OK with no/no and 
yes/yes parts of the table.

>2.  similarly, if the client does do STARTTLS, if the server is *listed* in
>DNS as an MX for the recipient's domain, it should not refuse to accept the
>mail because the server doesn't recognize the client's credentials, or
>because the server doesn't like the ciphersuite used, etc.
>the server should act like is specified in the second row in the table above.
>
>in other words, if the client is talking to a publically-listed server,
>and has a proper implementation of TLS, its use of STARTTLS shouldn't lessen
>the chance that the mail will be delivered.

That sounds right, but I would like to hear specific wording on it.


>3. also in section 5
>
>I don't understand the reason for this being a MUST:
>
>     Servers MUST be able to understand backwards compatible SSL Client
>     Hello messages (provided that client_version is TLS 1.0 or later),
>     and clients MAY use backwards compatible Client Hellos messages.
>     Neither clients or servers are required to actually offer Client
>     Hello messages for anything other than TLS 1.0.
>
>I can see it being a SHOULD, but why should we insist that a SMTP server
>that supports STARTTLS, also support outdated and nonstandard versions of SSL?
>
>Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?

This was also noted by some TLS folks. Bodo Möller suggested the 
following replacement:

      Clients MAY use backwards compatible SSL Client Hello message
      formats.  However, except for SSL session resumption, Client
      Hello messages MUST be suitable for negotiating TLS 1.0 or later
      (i.e. the version field of SSL 2.0 compatible Client Hello
      messages or the client_version field of SSL 3.0 compatible Client
      Hello messages must be at least 3.1).

      Servers MUST be able to understand backwards compatible SSL
      Client Hello messages, provided that the client indicates that
      it supports TLS 1.0 or later.

      Note that neither clients nor servers are required to actually
      support protocol versions other than TLS 1.0; but the above rules
      make sure that clients can operate in a backwards-compatible mode
      without risking interoperability with servers following the
      current specifications.


>4. in section 7
>
>     An SMTP client can partially protect against these attacks 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.
>
>it seems quite reasonable to explicitly configure a client to insist
>on the server supporting TLS, and refusing to send a message to the
>server if it doesn't advertise STARTTLS.  this also seems safer than
>the "automatic discovery" mechanism above.

This was discussed at length during the first round on this document, 
and the consensus was to use the words that are here. What you 
propose does not go against the words in section 7 *if the client is 
the orignator of the message*. If the client is an SMTP relay, what 
you are proposing would cause mail to bounce, and that was decided to 
be A Bad Thing.

>and if there is explicit configuration to require STARTTLS along a
>particular path, it seems perfectly reasonable for the client to refuse to
>relay the message for as long as the server fails to support STARTTLS,
>which could eventually result in a bounced message if delivery times out.

Again, that was not the consensus of the group.

>5. also in section 7
>
>     The STARTTLS extension is not suitable for authenticating the author
>     of an email message unless every hop in the delivery chain, including
>     the submission to the first SMTP server, is authenticated.
>
>this isn't a sufficient condition.  you not only need for each hop to
>be authenticated, you need to have established trust in each MTA that
>handles the message.

Good point. I'll add that.

--Paul Hoffman, Director
--Internet Mail Consortium