[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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